The Artima Developer Community
Sponsored Link

Object Mobility in the Jini Environment
Simplify the Installation and Configuration of Jini Applications
by Frank Sommers
First Published in JavaWorld, January 2001

<<  Page 3 of 9  >>


The Benefits of Object Serialization

The JVM is able not only to load classes, but also to load objects (instances of classes) from the network via the Java object serialization mechanism (see the Java Object Serialization Specification for more details). Object serialization stores an object in a stream (i.e., in serialized form) in such a way that a Java program can reconstruct the object's state at a later time. You can save the binary stream representing the serialized object on stable storage, such as in a file or in a database management system, or send it over a wire.

For an object to be serialized, it has to implement either the or interfaces, the latter being a subtype of Serializable. Serializable is a marker interface: it specifies no methods and merely indicates an object that has serializable state. All subclasses of a Serializable class are also serializable.

If instances of a class need a special way to serialize their state, that class can implement the Externalizable interface, which mandates two methods:

  void readExternal(ObjectInput inputStream);
  void writeExternal(ObjectOutput outputStream);

The main difference between Externalizable and Serializable is that the latter serializes, by default, the entire object graph, including states of an object's superclass. Externalizable gives you complete control over the serialization process.

If a supertype of a Serializable object is not itself serializable, then the object can assume the responsibility for saving and reconstructing the supertype's state (public, protected, and package fields if they share a package). For this to work, the superclass must have a public no-arg constructor. Further, if an object at runtime refers to a nonserializable object, the serialization system will throw a NotSerializableException, since it cannot write the complete object graph to the serialized stream.

Not all objects are suitable for serialization. Threads, for instance, do not have state that can later be recreated. (Actually, it is possible, but very difficult, to do so.) There can also be objects that should not be serialized for semantic reasons. Even if an object is serializable, you may not need to write all object fields to the stream during serialization. For instance, a variable that loses its meaning in a different execution context (such as something indicating the current time) should be marked transient, and will instead be initialized to its default value when reading it from the stream.

If an object holds multiple references to another object, this second object is serialized only once, and subsequent references to it will include a handle as a reference instead.

Along with instance data, the object serialization system writes a special object to the stream to represent the serializable object's class. This object is of the type, and is essentially a descriptor for the Class object associated with the serializable object. It contains the class's name, its unique version number (serialVersionUID), and the class fields. In addition, it also has methods to obtain the actual class represented by this object, if, and only if, this class is already present in the local VM:

  Class forClass();

If there is no class identified in the local VM that corresponds to this ObjectStreamClass, then a null value is returned.

Figure 2. An object graph written to a serialized stream

<<  Page 3 of 9  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use