Month: July 2014

Executables contained in the Java JDK and JRE

New article: Executables within the JDK and JRE. We certainly know common executables like javac.exe and java.exe – but when looking into the bin directories of a JRE or JDK installation, there are a lot more executables. What is their purpose? This article lists and briefly describes the various executables which can be found in an Java JRE’s or JDK’s bin directory. For some of the more interesting tools, screenshots and simple usage examples are also shown. In addition, each tool is linked to its official documentation, as long as it is available.

Programmatically iterating a RowSet

I have some tool method which I have been using to dump the contents of a RowSet, especially for debugging and testing purposes. At the core, the method looks like this:

void listRowSet(RowSet rowSet) {
    while(rowSet.hasNext()) {
        Row row = rowSet.next();

        // ... dump the contents of the current row
    }
}

and the result looks similar to this, dumping all the attributes in each row:

CId        | CCreated              | CLastupdated          
-----------------------------------------------------------
0          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 
1          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 
2          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 

Now, in a larger application, I was using the RowSet at several places, and I thought it would be a good idea to have the method always start at the first entry, and not rely on the fact that the iterator is already at the beginning when calling the method. This is what the RowIterator.reset() method is for. So, that seems to be easy:

void listRowSet(RowSet rowSet) {
    rowSet.reset();
    while(rowSet.hasNext()) {
        Row row = rowSet.next();

        // ... dump the contents of the current row
    }
}

Now, the result looks like this:

CId        | CCreated              | CLastupdated          
-----------------------------------------------------------
1          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 
2          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 

Ehmmm… Wait … Something’s wrong here … I have reset the iterator, but now the first row is missing? What is going on? Lets review the documentation of RowIterator.reset():

After this method, the current slot status will be SLOT_BEFORE_FIRST [...]

Alright, I know that concept from JDBC – there, the method is called beforeFirst(), and subsequent calls to next() move the cursor to the next row, which is the first one when next() is called for the first time. So, what is wrong here? Lets see – there is some additional information in the Javadoc:


...  except in cases where this iterator is associated to an iterator binding in an ADF
 application which sets the currency to the first row in the iterator if available.

Naturally, I skipped that part when I first looked up the documentation – but it looks like this is an important detail! On a side note, the next sentence in the Javadoc says

A subsequent invocation of next() will cause the first row to become the current row.

which is confusing, since this is exactly not the case when “this iterator is associated to an iterator binding in an ADF application which sets the currency to the first row in the iterator if available.”. Now that I know the problem, a quick search showed up a nice posting from Michael Koniotakis: Iterating through View Object RowIterator Bug.(NOT ADF BUG, Development Bug), and the suggestion is to use a secondary row iterator whenever iterating through a RowSet programmatically:

void listRowSet(ViewObject vo) {
    RowSetIterator iter = vo.createRowSetIterator(null); 
    while(iter.hasNext()) {
        Row row = iter.next();

        // ... dump the contents of the current row
    }
    iter.closeRowSetIterator();
}

With that, I now get all rows again, starting at the first row:

CId        | CCreated              | CLastupdated          
-----------------------------------------------------------
0          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 
1          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 
2          | 2014-07-04 13:16:46.0 | 2014-07-04 13:16:46.0 

Instead of the ViewObject, we can also use a RowSet to create the new iterator (remember that a ViewObject is a RowSet), so that the method signature can remain unchanged:

void listRowSet(RowSet rowSet) {
    RowSetIterator iter = rowSet.createRowSetIterator(null); 
    while(iter.hasNext()) {
        Row row = iter.next();

        // ... dump the contents of the current row
    }
    iter.closeRowSetIterator();
}

Returning values from a bash function

bash does not provide a return statement to return custom values from a function. The return statement is only used to return a numeric status code to the calling function which can be retrieved with $?. Long story made short, use a recent bash version (>= 4.3) and use the declare -n statement to declare a reference to the variable where the result will be stored, and pass the name of this variable as a parameter to the function:

#!/bin/bash

someFunction() {
    declare -n __resultVar=$1
    local someValue="Hello World"

    # The next statement assigns the value of the local variable to the variable
    # passed as parameter
    __resultVar=${someValue}
}

# call the function and pass the name of the result variable
someFunction theResult
echo ${theResult}

Name service request caching with nscd

Sometimes it is still easiest (especially when there is only a command line terminal available) to directly edit files like /etc/passwd, /etc/hosts etc. with a plain text editor. When I today just wanted to change the login shell of a user on an Oracle Enterprise Linux installation, I simply changed /bin/csh to /bin/bash for the corresponding entry in /etc/passwd. However, the surprise was that the new entry was not considered when re-logging in. This is where nscd comes into play. From the man page:

NSCD(8)                    Linux Programmer's Manual                   NSCD(8)

NAME
       /usr/sbin/nscd - name service cache daemon

DESCRIPTION
       Nscd  is a daemon that provides a cache for the most common name service requests.  ...

Among those most common name service requests are lookups into the /etc/hosts, /etc/group and /etc/hosts files. Actually the nscd daemon also watches the respective files for changes, but it might take several minutes until it picks up the modified files.To clear the nscd cache immediately, simply call nscd with the -i switch and the name of the lookup database which needs to be reloaded:

$ /usr/sbin/nscd -i passwd

By the way, stopping and re-starting the nscd daemon through /etc/init.d/nscd is not enough – the daemon still remembers its cached entries afterwards.