It’s not clear why you think that enum types were not lazily initialized. There is no difference to other class types:
public class InitializationExample {
public static void main(String[] args) {
System.out.println("demonstrating lazy initialization");
System.out.println("accessing non-enum singleton");
Object o = Singleton.INSTANCE;
System.out.println("accessing the enum singleton");
Object p = SingletonEnum.INSTANCE;
System.out.println("q.e.d.");
}
}
public enum SingletonEnum {
INSTANCE;
private SingletonEnum() {
System.out.println("SingletonEnum initialized");
}
}
public class Singleton {
public static final Singleton INSTANCE = new Singleton();
private Singleton() {
System.out.println("Singleton initialized");
}
}
demonstrating lazy initialization
accessing non-enum singleton
Singleton initialized
accessing the enum singleton
SingletonEnum initialized
q.e.d.
Since the laziness is already there in either case, there is no reason to use a nested type as in your serializable singleton example. You could still use the simpler form
public class SerializableSingleton implements Serializable {
public static final SerializableSingleton INSTANCE = new SerializableSingleton();
private static final long serialVersionUID = 1L;
private SerializableSingleton() {
System.out.println("SerializableSingleton initialized");
}
protected Object readResolve() {
return INSTANCE;
}
}
The difference to an enum is that fields are indeed getting serialized, but there’s no point in doing so as after deserializing, the reconstructed object gets replaced with the current runtime’s singleton instance. That’s what the readResolve() method is for.
This is a semantic problem, as there can be an arbitrary number of different serialized versions but only one actual object, as otherwise it wouldn’t be a singleton anymore.
Just for completeness,
public class SerializableSingleton implements Serializable {
public static final SerializableSingleton INSTANCE = new SerializableSingleton();
private static final long serialVersionUID = 1L;
int value;
private SerializableSingleton() {
System.out.println("SerializableSingleton initialized");
}
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
protected Object readResolve() {
System.out.println("replacing "+this+" with "+INSTANCE);
return INSTANCE;
}
public String toString() {
return "SerializableSingleton{" + "value=" + value + '}';
}
}
SerializableSingleton single = SerializableSingleton.INSTANCE;
single.setValue(42);
byte[] data;
try(ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos)) {
oos.writeObject(single);
oos.flush();
data = baos.toByteArray();
}
single.setValue(100);
try(ByteArrayInputStream baos = new ByteArrayInputStream(data);
ObjectInputStream oos = new ObjectInputStream(baos)) {
Object deserialized = oos.readObject();
System.out.println(deserialized == single);
System.out.println(((SerializableSingleton)deserialized).getValue());
}
SerializableSingleton initialized
replacing SerializableSingleton{value=42} with SerializableSingleton{value=100}
true
100
So there’s no behavioral advantage in using an ordinary class here. Storing the fields contradicts the singleton nature and in the best case, these values have no effect and the deserialized object gets replaced by the actual runtime object, just like an enum constant is deserialized to the canonical object in the first place.
Also, there is no difference regarding lazy initialization. So the non-enum class requires more code to write to get with nothing better.
The fact that the readResolve() mechanism requires deserializing an object first, before it can be replaced by the actual result object is not only inefficient, it violates the singleton invariant temporarily and this violation is not always cleanly resolved at the end of the process.
This opens the possibility to the Serialization hack:
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.Serializable;
public class TestSer {
public static void main(String[] args) throws IOException, ClassNotFoundException {
SerializableSingleton singleton = SerializableSingleton.INSTANCE;
String data = "’\0\5sr\0\25SerializableSingleton\0\0\0\0\0\0\0\1\2\0\1L\0\1at\0\10"
+ "LSneaky;xpsr\0\6SneakyOÎæJ&r\234©\2\0\1L\0\1rt\0\27LSerializableSingleton;"
+ "xpq\0~\0\2";
try(ByteArrayInputStream baos=new ByteArrayInputStream(data.getBytes("iso-8859-1"));
ObjectInputStream oos = new ObjectInputStream(baos)) {
SerializableSingleton official = (SerializableSingleton)oos.readObject();
System.out.println(official+"\t"+(official == singleton));
Object inofficial = Sneaky.instance.r;
System.out.println(inofficial+"\t"+(inofficial == singleton));
}
}
}
class Sneaky implements Serializable {
static Sneaky instance;
SerializableSingleton r;
Sneaky(SerializableSingleton s) {
r = s;
}
private Object readResolve() {
return instance = this;
}
}
SerializableSingleton initialized
replacing SerializableSingleton@bebdb06 with SerializableSingleton@7a4f0f29
SerializableSingleton@7a4f0f29 true
SerializableSingleton@bebdb06 false
Also on Ideone
As demonstrated, the readObject() returns the canonical instance as intended, but our Sneaky class provides access to the second instance of the “singleton” which was supposed to be of a temporary nature.
The reason why this works, is precisely because fields are serialized and deserialized. The specially constructed (sneaky) stream data contains a field which actually doesn’t exist in the singleton, but since the serialVersionUID matches, the ObjectInputStream will accept the data, restore the object and then drop it because there’s no field to store it. But at this time, the Sneaky instance got already hands on the singleton via a cyclic reference and remembers it.
The special treatment of enum types make them immune against such attacks.
