CONTENTS | PREV | NEXT | Java Object Serialization Specification |
When objects are declared to be serializable so that they can be written to or read from a stream, the class designer must take care that the information saved for the class is appropriate for persistence and follows the serialization-specified rules for evolution and interoperability. Serialized streams of objects must interoperate over time and across versions of the classes that are written to and read from them. Specifying the serializable fields of the class makes it possible for classes to evolve and still be able to communicate with previous as well as future versions of the class. This is an essential feature and benefit of using serialization for persistence or for communication. Chapter 5, "Versioning of Serializable Objects," explains class evolution in greater detail.For a class that is declared Serializable, the serializable state of the object is defined by serializable fields (by name and type) plus optional data. Optional data can only be written explicitly by a Serializable class. Optional data can be read by the Serializable class or serialization will skip unread optional data. By default, the non-transient and non-static fields of the class define the set of serializable fields. This default set of fields can be overridden by declaring the set of serializable persistent fields. See Section 1.6, "Defining Serializable Fields for a Class," for additional information.
For classes that are declared Externalizable, the serialized state is defined by the data written to the stream by the class itself. It is up to the class to specify the order, types, and meaning of each datum written to the stream. It is up to the class to handle its own evolution so that it can continue to read data written by previous versions and that it writes data that can be read by previous versions. The class must coordinate with the superclass when saving and restoring data. The location of the superclasses data in the stream must be specified.
Regardless of the serialization mechanism chosen, the specification must define the fields as if they were fields of the object using the Java(tm) specifications for names and types. Optional data written to the stream must be specified by sequence and type. The meaning associated with serializable fields and data must be defined. For example, a class Window has a field named "background" that refers to a Color object that is to be used to fill the part of the window not otherwise covered. These serializable fields may correspond directly to declarations in the class or may only be accessible via get and set methods described below. Independent of the mechanism used to make the serializable field visible to the client, the semantics of the object are expressed in terms of these values. The initial or default value must be specified for each value. Classes may or may not have other fields which are not part of the serializable state of the object.