Item 75: Consider using a custom serialized form

1.  Do not accept the default serialized form without first considering whether it is appropriate. Accepting the default serialized form should be a conscious decision that this encoding is reasonable from the standpoint of flexibility, performance, and correctness.

 

2.  The default serialized form of an object is a reasonably efficient encoding of the physical representation of the object graph rooted at the object. In other words, it describes the data contained in the object and in every object that is reachable from this object. It also describes the topology by which all of these objects are interlinked. 

 

3.  The ideal serialized form of an object contains only the logical data represented by the object. It is independent of the physical representation. The default serialized form is likely to be appropriate if an object’s physical representation is identical to its logical content.

 

4.  Even if you decide that the default serialized form is appropriate, you often must provide a readObject method to ensure invariants and security.

 

5.  The presence of the @serial tag tells the Javadoc utility to place this documentation on a special page that documents serialized forms. Like the @serial tag for fields, the @serialData tag for methods tells the Javadoc utility to place this documentation on the serialized forms page.

 

6.  Using the default serialized form when an object’s physical representation differs substantially from its logical data content (a doubly linked list) has four disadvantages:

    1)  It permanently ties the exported API to the current internal representation.

    2)  It can consume excessive space for implementation details.

    3)  It can consume excessive time. (Following the previous link for doubly linked list is not necessary.)

    4)  It can cause stack overflows. The default serialization procedure performs a recursive traversal of the object graph, which can cause stack overflows even for moderately sized object graphs.

 

7.  If all instance fields are transient, it is technically permissible to dispense with invoking defaultWriteObject and defaultReadObject, but it is not recommended. Even if all instance fields are transient, invoking defaultWriteObject affects the serialized form, resulting in greatly enhanced flexibility. The resulting serialized form makes it possible to add nontransient instance fields in a later release while preserving backward and forward compatibility. If an instance is serialized in a later version and deserialized in an earlier version, the added fields will be ignored. Had the earlier version’s readObject method failed to invoke defaultReadObject, the deserialization would fail with a StreamCorruptedException.

 

8.  Before deciding to make a field nontransient, convince yourself that its value is part of the logical state of the object. If you use a custom serialized form, most or all of the instance fields should be labeled transient.

 

9.  If you are using the default serialized form and you have labeled one or more fields transient, remember that these fields will be initialized to their default values when an instance is deserialized: null for object reference fields, zero for numeric primitive fields, and false for boolean fields

 

10.  Whether or not you use the default serialized form, you must impose any synchronization on object serialization that you would impose on any other method that reads the entire state of the object.

 

11.  Regardless of what serialized form you choose, declare an explicit serial version UID in every serializable class you write. This eliminates the serial version UID as a potential source of incompatibility:

private static final long serialVersionUID = randomLongValue;

 

12.  If you modify an existing class that lacks a serial version UID, and you want the new version to accept existing serialized instances, you must use the value that was automatically generated for the old version. You can get this number by running the serialver utility on the old version of the class—the one for which serialized instances exist.