Serialization

88. Use defensive copies when deserializing

Similar to item 50, if you want to keep the advantages of an immutable object when implementing Serializable, it is required to make defensive copies of any none-primitive field.

This is because the readObject-method should be viewed as an alternative to a normal constructor of the object.

Date dateTwo = new Date(dateOne.getTime());

89. Singletons and serializability

Any singleton class which implements the serializable interface, can no longer be a singleton. This is because of the readObject() method, which is automatically implemented to deserialize the object and create a new instance.

In order to make the class remain a singleton, it is necessary to implement the readResolve() method, which is automatically called directly after readObject().

Within the readResolve() method, the object is then to return the intended singleton instance of the class instead of the new deserialized object. For this scenario, it would be recommended to return the object as an enum instance.

90. Utilize the serialization proxy pattern

Implementing Serializable on any class, introduces the risk of bugs and errors associated with serializing and deserializing.

To avoid or limit this risk, it is recommendable to use the serialization proxy pattern.

The pattern evolves around having a copy of the concrete class (aka. proxy), which replaces it through the writeReplace() method.

Within the proxy the constructor takes in an instance of the concrete class as its only argument and assign it to its fields.

Then the proxy overrides the readResolve() and returns an instance of the concrete class.

Finally, the concrete class overrides its own readObject() method and implements a thrown exception to ensure that it is never called directly, but only through the proxy.