Can this Java singleton get rebuilt repeatedly in WebSphere 6?

Question

I\'m trying to track down an issue in our system and the following code worries me. The following occurs in our doPost() method in the primary servlet (names have been changed

Answer 1

It's not mandatory for the single instance to be final (it's not a good idea at all indeed, because this will avoid you to switch it's behaviour using other patterns).

In the code below you can see how it gets instantiated only once (first time you call the constructor)

package date;

import java.util.Date;

public class USDateFactory implements DateFactory { private static USDateFactory usdatefactory = null;

private USDateFactory () { }

public static USDateFactory getUsdatefactory() {
    if(usdatefactory==null) {
        usdatefactory = new USDateFactory();
    }
    return usdatefactory;
}

public String getTextDate (Date date) {
    return null;
}

public NumericalDate getNumericalDate (Date date) {
    return null;
}

}

Answer 2

As others have mentioned, the static initializer will only be run once per classloader.

One thing I would take a look at is the firstTime() method - why can't the work in doPreparations() be handled within the singleton itself?

Sounds like a nasty set of dependencies.

Answer 3

The only thing I would change about that Singleton implementation (other than not using a Singleton at all) is to make the instance field final. The static field will be initialised once, on class load. Since classes are loaded lazily, you effectively get lazy instantiation for free.

Of course, if it's loaded from separate class loaders you get multiple "singletons", but that's a limitation of every singleton idiom in Java.

EDIT: The firstTime() and doPreparations() bits do look suspect though. Can't they be moved into the constructor of the singleton instance?

Answer 4

This will get only loaded once when the class is loaded by the classloader. This example provides a better Singleton implementation however, it's as lazy-loaded as possible and thread-safe. Moreover, it works in all known versions of Java. This solution is the most portable across different Java compilers and virtual machines.

public class Single {

private static class SingleHolder {
   private static final Single INSTANCE = new Single();
}

private Single() {
...load properties...
}

public static Single getInstance() {
    return SingleHolder.INSTANCE;
}

}

The inner class is referenced no earlier (and therefore loaded no earlier by the class loader) than the moment that getInstance() is called. Thus, this solution is thread-safe without requiring special language constructs (i.e. volatile and/or synchronized).