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.

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:
java.naming.provider.url=server1.sample.net:1100,server2.sample.net:1100

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:
jnp.timeout=1500
jnp.sotimeout=2000

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.