A bean has the property of persistence when its properties, fields, and state information are saved to and retrieved from storage. Component models provide a mechanism for persistence that enables the state of components to be stored in a non-volatile place for later retrieval.
The mechanism that makes persistence possible is called serialization . Object serialization means converting an object into a data stream and writing it to storage. Any applet, application, or tool that uses that bean can then "reconstitute" it by deserialization. The object is then restored to its original state.
For example, a Java application can serialize a Frame window on a Microsoft Windows machine, the serialized file can be sent with e-mail to a Solaris machine, and then a Java application can restore the Frame window to the exact state which existed on the Microsoft Windows machine.
Any applet, application, or tool that uses that bean can then "reconstitute" it by deserialization.
All beans must persist. To persist, your beans must support serialization by implementing either the java.io.Serializable (in the API reference documentation) interface, or the java.io.Externalizable (in the API reference documentation) interface. These interfaces offer you the choices of automatic serialization and customized serialization. If any class in a class's inheritance hierarchy implements
Externalizable , then that class is serializable.
Any class is serializable as long as that class or a parent class implements the
java.io.Serializable interface. Examples of serializable classes include
Vector , and
Hashtable . Thus, any subclass of the
Component class, including
Applet , can be serialized. Notable classes not supporting serialization include
Socket , and
InputStream . Attempting to serialize objects of these types will result in an
The Java Object Serialization API automatically serializes most fields of a Serializable object to the storage stream. This includes primitive types, arrays,and strings. The API does not serialize or deserialize fields that are marked transient or static.
You can control the level of serialization that your beans undergo. Three ways to control serilization are:
Automatic serialization, implemented by the
Serializableinterface. The Java serialization software serializes the entire object, except transient and static fields.
Customized serialization. Selectively exclude fields you do not want serialized by marking with the
Customized file format, implemented by the
Externalizableinterface and its two methods. Beans are written in a specific file format.
Serializable interface provides automatic serialization by using the Java Object Serialization tools.
Serializable declares no methods; it acts as a marker, telling the Object Serialization tools that your bean class is serializable. Marking your class
Serializable means you are telling the Java Virtual Machine (JVM) that you have made sure your class will work with default serialization. Here are some important points about working with the
Classes that implement
Serializablemust have an access to a no-argument constructor of supertype. This constructor will be called when an object is "reconstituted" from a
You don't need to implement
Serializablein your class if it is already implemented in a superclass.
All fields except static and transient fields are serialized. Use the
transientmodifier to specify fields you do not want serialized, and to specify classes that are not serializable.
To exclude fields from serialization in a
Serializable object mark the fields with the
transient int status;
Default serialization will not serialize
If your serializable class contains either of the following two methods (the signatures must be exact), then the default serialization will not take place.
private void writeObject(java.io.ObjectOutputStream out) throws IOException; private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
You can control how more complex objects are serialized, by writing your own implementations of the
readObject methods. Implement
writeObject when you need to exercise greater control over what gets serialized when you need to serialize objects that default serialization cannot handle, or when you need to add data to the serialization stream that is not an object data member. Implement
readObject to reconstruct the data stream you wrote with
Externalizable interface when you need complete control over your bean's serialization (for example, when writing and reading a specific file format). To use the
Externalizable interface you need to implement two methods:
writeExternal . Classes that implement
Externalizable must have a no-argument constructor.