1.10 The Serializable Interface

Object Serialization produces a stream with information about the Java^TM classes for the objects which are being saved. For serializable objects, sufficient information is kept to restore those objects even if a different (but compatible) version of the implementation of the class is present. The Serializable interface is defined to identify classes which implement the serializable protocol:

package java.io;

public interface Serializable {};

A Serializable class must do the following:

• Implement the java.io.Serializable interface
• Identify the fields that should be serializable

(Use the serialPersistentFields member to explicitly declare them serializable or use the transient keyword to denote nonserializable fields.)

• Have access to the no-arg constructor of its first nonserializable superclass

The class can optionally define the following methods:

• A writeObject method to control what information is saved or to append additional information to the stream
• A readObject method either to read the information written by the corresponding writeObject method or to update the state of the object after it has been restored
• A writeReplace method to allow a class to nominate a replacement object to be written to the stream

(See Section 2.5, "The writeReplace Method" for additional information.)

• A readResolve method to allow a class to designate a replacement object for the object just read from the stream

(See Section 3.7, "The readResolve Method" for additional information.)

ObjectOutputStream and ObjectInputStream allow the serializable classes on which they operate to evolve (allow changes to the classes that are compatible with the earlier versions of the classes). See Section 5.5, "Compatible Java^TM Type Evolution" for information about the mechanism which is used to allow compatible changes.

---

Note - Serialization of inner classes (i.e., nested classes that are not static member classes), including local and anonymous classes, is strongly discouraged for several reasons. Because inner classes declared in non-static contexts contain implicit non-transient references to enclosing class instances, serializing such an inner class instance will result in serialization of its associated outer class instance as well. Synthetic fields generated by javac (or other Java^TM compilers) to implement inner classes are implementation dependent and may vary between compilers; differences in such fields can disrupt compatibility as well as result in conflicting default serialVersionUID values. The names assigned to local and anonymous inner classes are also implementation dependent and may differ between compilers. Since inner classes cannot declare static members other than compile-time constant fields, they cannot use the serialPersistentFields mechanism to designate serializable fields. Finally, because inner classes associated with outer instances do not have zero-argument constructors (constructors of such inner classes implicitly accept the enclosing instance as a prepended parameter), they cannot implement Externalizable. None of the issues listed above, however, apply to static member classes.

---