What Is Object Serialization?

To this point, you've been working with objects and ways to manipulate those objects through the methods defined on them. You have created an application, started it, and instantiated some objects. When that application exited, those objects ”or really the state of those objects ”was lost. To keep that from happening, you need to learn how to save that state for later retrieval.

The term for saving the state of an object to an external source so that it can be constructed later is usually known as persistence. In other words, you will want to ensure that the object persists over a longer life cycle than just the execution of an application. Later when you learn about JDBC and Databases, you'll also get more detail about how to persist an object state to a database. However, a database is not needed for every application. Some applications have no need to persist object states after the exit of the application. For some applications, installing and creating a database is a giant overkill. For those types of applications, you really need a smaller method of persisting object states. This is one place that Object serialization can help.

Another use of Object serialization is that it allows an application to communicate objects across a network and be reconstituted back into an object on the other side (discussed further in Chapter 23, "Communications and Networking" ). Object serialization is the tool that was added to Java to allow you to fully use the Object Oriented Programming nature of Java and write those objects you've labored to produce to a file or other stream so that they can be persisted or shared with other applications.

To understand object serialization, first look at how you would persist an object to a file so that it can be read back in later. This approach assumes that you have one or more objects that needed to be persisted and a database is too much. Normally when you open a stream to and from a client program, the odds are good that you are sending/receiving some type of primitive data types, such as an int or a byte. Persisting an object in this manner means that for each attribute that is within the object, it needs to be manually written out to the file. If an object has a reference to another object or a collection of objects, it gets extremely complicated very quickly.

If you really wanted to, you could write generalized methods to handle some of the redundant work, but you would still be faced with some problems. Fortunately, object serialization enables you to grab an object a whole class at a time.

If you need to store or send complete object instances to a file or over the network, object serialization makes this an easy chore to perform.

How Object Serialization Works

The key to object serialization is to store enough data about the object to be able to reconstruct it fully. Furthermore, to protect the user (and programmer), the object must have a "fingerprint" that correctly associates it with the legitimate object from which it was made. This fingerprint is actually the class name and signature of the class, the values of the object's fields and arrays, and the closure of any other objects referenced from the initial objects. Non-transient and static fields are not serialized. That probably sounds like a lot of work and things to write out. Fortunately, the handling of all of this complexity is taken care of by the Java Virtual Machine, and the Java developer just needs to call the appropriate write methods. This normally is as easy as calling something like this:

 writeObject( someObject ); 

It's not necessary, however, for the serialization routines to store the methods of a class. The class code is assumed available any time these elements are required. In other words, when you store an instance of the class Date, you are not also storing the methods for that class. It's assumed that you are using the same Date class to reconstitute the object that was used to serialize it.

Object serialization can take advantage of using streams to make the writing out of objects even easier (you learned about streams in Chapter 21, "Streams, Files, and Serialization" ) However, only objects supporting the java.io.Serializable interface can be written to streams. When an object is written out to a stream or to the network, it's critical that it be read back in the exact sequence that it was written out or the object will not be able to be reconstructed. So if multiple objects are written out, they must be read in the same order. This method is easier than writing the attributes of an object out, because you don't have to keep track of which attribute was written out and in which order. Also, the type of attribute must be tracked if you simply write the attributes of an object out. Using object serialization, this is all handled for the developer. It's as easy as calling the writeObject and readObject methods.

Note

If you are a C or C++ programmer, you're probably used to accomplishing much of object serialization by taking the pointer to a class or struct, doing a sizeOf(), and writing out the entire class. Java does not support pointers or direct-memory access, so this technique will not work in Java, and object serialization is required.

Dealing with Objects with Object References

Objects frequently refer to other objects by declaring instance variables that reference the other class. For example, in the TestObject class in Listing 22.3, a nextNode private instance variable is a reference to an object of type TestObject. To persist an object, it is also necessary to persist the objects that these objects reference. Of course, the reference objects might also refer to yet even more objects. So, as a rule, to serialize an object completely, you must store all the information for that object, as well as every object that is reachable by the object, including all the recursive objects.

Prior to SDK 1.3, Strings longer than 64K could not be serialized. That is no longer a problem with the SDK 1.3 version. There has also been several performance improvements for serialization within the 1.3 version. The improvements revolved around removing unnecessary synchronization/method call overhead during serialization. These two improvements alone make serialization more attractive than the previous editions.

Listing 22.1 Source Code for TestObject.java

 public class TestObject {   // Private instance variables   private int x;   private int y;   private float angle;   private String name = null;   private TestObject nextNode = null;   // Constructor   public TestObject (int x, int y, float angle, String name, TestObject nextNode) {     super();     this.x = x ;     this.y = y;     this.angle= angle;     this.name = name;     this.nextNode = nextNode;   } }