Class-Specific Serialization

Sometimes the data members that are marked as transient are an important part of the run-time state of the object. Consider a class that maintains an instance of a java.io.FileOutputStream, a class that cannot be serialized because it uses a file handle. It would be dangerous to save the handle because it is allocated at run-time, and the objects may be reconstructed on another system that uses a different scheme for allocating file handles. Also, if the file handle were to be saved it could be modified to resemble a handle that is not normally accessible. This would be a security violation, and could even result in unwanted or malicious behavior. Nevertheless, when the object is reconstructed, we would want to reestablish the instance of the java.io.FileOutputStream. We might handle this by saving the name of the file along with the current value of the seek offset.

It is possible to extend the default serialization behavior. Any class that implements java.io.Serializable can implement its own writeObject() and readObject() methods for this purpose.

If you want the serialization mechanism to ask your object to write its own data, it should provide a writeObject() method with the following signature:

private void writeObject(ObjectOutputStream stream)
               throws java.io.IOException;

If this method exists, the data members will not automatically be serialized. It is up to the writeObject() method to store the state of the object. However, it doesn’t need ...

Get Developing Java Beans now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.