Wednesday, April 30, 2008

variable arguments in java

I have to confess that I totally missed out on Varargs in Java. This is embarrasing. Yesterday I have been searching for a method in Sesame ( that takes (among others) 3 Resource instances as parameters. I could not find it although the code compiled and I did call it. Guess why ;-).

I don't think it's a good idea to use that Java 5! language feature. It can lead to poor traceability and to error-prone code. Instead I would always use collections. What do you think?

Here's an example in case someone else missed out on it too:

public class VarargTest {

public static void func(String p1, String... args) {
for(String arg : args) System.out.println(arg);

public static void main(String args[]) {

Saturday, March 8, 2008

how to create instances of primitive wrapper

I have found out that it can be faster to obtain new instances of primitive wrapper classes such as Integer or Long via the static valueOf method than using the new operator. The reason is that most wrapper classes contain an internal cache of frequently requested instances.

If we take a look at the javaSE 6 source code we can see that the Long class for instance creates a cache inside the static block of an inner class:
private static class LongCache {
private LongCache() { }
static final Long cache[] = new Long[-(-128) + 127 + 1];
static {
for (int i = 0; i < cache.length; i++)
cache[i] = new Long(i - 128);
public static Long valueOf(long l) {
final int offset = 128;
if (l >= -128 && l <= 127) {
return LongCache.cache[(int)l + offset];
return new Long(l);

The main difference is that new will always return a brand new instance whereas the valueOf method may return an “old” object that has been created and cached in advance. The downside of this approach is that the first call of valueOf will create all instance for the cache.

The Double and Float wrapper classes just call new inside the valueOf method. There is no sign of any caching at all in their implementation. All other wrapper classes (Byte, Character, Boolean, ...) have a caching mechanism similar to the example above.

Saturday, March 1, 2008

timeout on JNDI lookup

for a jboss.remoting EJB client there are two ways of discovering the available servers on the net. one approach is to send multicast packages and wait for the servers to respond. this kind of auto-discovery only works if the servers are able to receive multicast packages from the clients which often is not the case.

the other approach is to provide a list of servers in the JNDI properties:,

all the servers in the list will be tried out sequentially. if one of the servers is not responding it may take a while until the client recognizes that and proceeds with the next server in the list. to avoid a long and not deterministic timeout behaviour additional JNDI properties can be provided:

this is possible because the remoting client uses a special implementation of the SocketFactory by default. The TimedSocketFactory tries to connect to the server and aborts after a given timeout period. the jnp.timeout defines the amount of time the factory will wait for a response on the initial connect. the jnp.sotimeout specifies the period of time the factory will block the read operation on the connected socket waiting for an answer.

Tuesday, February 26, 2008