|CONTENTS | PREV | NEXT||Java Object Serialization Specification|
For serializable objects, the
readObjectmethod allows a class to control the deserialization of its own fields. Here is its signature:
private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException;Each subclass of a serializable object may define its own
readObjectmethod. If a class does not implement the method, the default serialization provided by
defaultReadObjectwill be used. When implemented, the class is only responsible for restoring its own fields, not those of its supertypes or subtypes.
readObjectmethod of the class, if implemented, is responsible for restoring the state of the class. The values of every field of the object whether transient or not, static or not are set to the default value for the fields type. The
defaultReadObjectmethod should be called before reading any optional data written by the corresponding
writeObjectmethod. If the
readObjectmethod of the class attempts to read more data than is present in the optional part of the stream for this class, the stream will throw an
EOFException. The responsibility for the format, structure, and versioning of the optional data lies completely with the class. The
@serialDatajavadoc tag within the javadoc comment for the
readObjectmethod should be used to document the format and structure of the optional data.
If the class being restored is not present in the stream being read, its fields are initialized to the appropriate default values.
Reading an object from the
ObjectInputStreamis analogous to creating a new object. Just as a new object's constructors are invoked in the order from the superclass to the subclass, an object being read from a stream is deserialized from superclass to subclass. The
defaultReadObjectmethod is called instead of the constructor for each
Serializablesubclass during deserialization.
One last similarity between a constructor and a
readObjectmethod is that both provide the opportunity to invoke a method on an object that is not fully constructed. Any non-final method called while an object is being constructed can potentially be overridden by a subclass. Methods called during the construction phase of an object are resolved by the actual type of the object, not the type currently being initialized by either its constructor or
readObjectmethod. This situation results in the overriding method being invoked on an object that is not fully constructed yet.