Bean Serialization

A Serializable object is serialized by calling the ObjectOutput.writeObject method, with the object as its parameter. To deserialize, the ObjectInput.readObject method is called. You, as a Bean creator, do NOT call these methods. What you do need to do is ensure your Bean is serializable.

1. Is your class Serializable?
2. Are all instance variables Serializable?
3. Do you want everything that isn't transient or static to be saved?
4. Should you serialize the object in its current structure?
5. How do I initialize transient and static variables upon deserialization?
6. Do you want to add a validator to the serialization process?

   If you're Serializable and want the default behavior for everything else, you're set and don't have to do anything extra. However, if not, you have something to do.

   The first is easy, does your class implement the Serializable interface (directly or indirectly)? If it doesn't, make it. (Note, there is also an Externalizable interface for when you need to control all aspect of Serialization, usually for security purposes.)

   For the second, check to see if all each instance variable is Serializable. Primitive datatypes are, by default. The rest you have to check manually, until you learn which aren't. (Image isn't). If one isn't, you need to figure out what to do about it. (For instance, image files can be kept separate and re-read when a Bean is deserialized.) Do you initialize it to a default value, make it transient, or provide some other means to initialize?

   The third is easy. Is it okay to save everything?

   Fourth, is it more efficient to save the data in a different format? For instance, it is more efficient to serialize a Hashtable's pieces, and recreate the structure, then to save the mostly empty hashtable. Also, should you encrypt the information?

   Fifth, is it okay to use default values for non-persistent variables? If not, you have to add code to handle this.

   Finally, do you want to validate the deserialized object network? Like, is your graph consistent? If yes, you need to register a validation method.

   For instance, if you wanted to have a Date instance variable of a class, but wanted it to be the 'last-created' date vs. a 'first-created' date, you could have a transient variable that is reset when deserialized:

   public class TreeNode implements Serializable {
     Vector children;
     TreeNode parent;
     String name;
     transient Date date;
     public TreeNode(String s) {
       children = new Vector(5);
       name = s;
       initClass();
     }
     private void initClass () {
       date = new Date();
     }
     ...
     private void writeObject(ObjectOutputStream s)
         throws IOException {
       s.defaultWriteObject();
     }
     private void readObject(ObjectInputStream s)
         throws ClassNotFoundException, IOException {
       s.defaultReadObject();
       initClass();
     }
   }
   

   Although the writeObject does the default functionality, whenever a readObject method is provided, a writeObject method is necessary. [complete source]

   Bean Reconstitution

   Normally, you call new when you want to create an instance of a class. With Beans, you can still do that, however, there is another way. The Beans.instantiate method is normally used by builder tools to recreate a Bean from a serialized Bean source. The reason being, tool vendors do not want to restrict what Beans you could use to only those it knew about when the tool was created. For instance, to create a TextField, without new, just call:

   Component c =
     (Component)Beans.instantiate(null, "java.awt.TextField");
   

   By itself, this is identical to Component c = new TextField(); However, before you get too excited, build on this a bit. First, create your own TextField class, by subclassing TextField.

   public class MyTextField extends java.awt.TextField {
   }
   

   Nothing fancy yet. But, create a little program to save a serialized MyTextField, with a couple of properties set:

   import java.awt.*;
   import java.io.*;
   
   public class TfSaver {
     public static void main(String args[]) {
       MyTextField mtf = new MyTextField();
   
       // set the properties
       Font ft = new Font("Serif", Font.ITALIC, 36);
       mtf.setFont(ft);
       mtf.setText("Hello World");
       
       // serialize
       try {
         FileOutputStream f = new FileOutputStream(
           "MyTextField.ser");
         ObjectOutputStream s = new ObjectOutputStream(f);
         s.writeObject(mtf);
         s.flush();
       } catch (Exception e) {
         System.out.println(e);
       }
       System.exit(0);
      }
   }
   

   Now, if you create an application that uses a MyTextField instance, it can start with the font and text properties already set (to 36-point italic Serif font and "Hello World" text).

   Component c =
     (Component)Beans.instantiate(null, "MyTextField");
   

   If a filename of the form Classname.ser exists (MyTextField.ser in this case), then the class is deserialized. Otherwise, the Bean will be created by using the default no-arg constructor of the class.

   With MyTextField.ser
   

   Without MyTextField.ser
   

   Bean Versioning

   Changes made to a Bean that change the persistence structure flag the new version as incompatible with the old, and prevents reconstitution. While this sounds good in theory, in practice it has its shortcomings. Adding any new method to a Bean makes the new class definition incompatible (for deserialization), resulting in a java.io.InvalidClassException being thrown. However, since a method does not add (or remove) any state information (behavior is not serialized), the two classes should be compatible. In order to ensure the new version can be reconstituted from the original, you need to add a Stream Unique Identifier (SUID) variable to your class definition.

   private static final long serialVersionUID =
       -2966288784432217853L;
   

   Then, when the versions are truly incompatible, you change the SUID variable. When this does happen, you should keep track of all the old values so you can properly handle the differences (e.g., default setting for new instance variable). If you forget to save the old setting, it is necessary to revert back to an old version, regenerating the value, and moving forward again.

   The values are generated from a hash algorithm, not randomly picked out of the air nor even a one-up numbering scheme. Since static variables are not serialized, the value is regenerated during deserialization and compared against the current class definition. The program to generate the values is serialver and has one argument of the classname. If you run the program with the -show argument instead, serialver displays a graphical interface, which allows you to cut and paste the results into your editor.

   

   Exercises

   1. BDK Introduction with John Wayne
   2. Packaging Central Perk with Marcel
   3. Getting Resources with Clara Barton
   4. Saving Billboards with Casey Kasem

   Resources

   Some web-based resources:
   • JavaBeans Home
   • The JavaBeans Advisor
   • JavaBeans FAQ
   • JavaBeans Tools
   • JavaBeans API Definitions
   • JavaBeans Related APIs
   • JavaBeans-ActiveX Bridge
   and books:
   • The JavaBeans Specification and Tutorial (Addison-Wesley)
   • Developing Java Beans (O'Reilly)
   • Design Patterns - Elements of Reusable Object-Oriented Software (Addison-Wesley) Gamma, Helm, Johnson, Vlissides (ISBN 0-201-63361-2).