Serialization & Versioning

Question

Hi,
I am wondering how serialization and versioning (I mean internal changes in a class is a different version of a class) go together.
For example I have a very simple class like this:
class A implements Serializable {
   private int a, b;
   private int version = 1;
   private static final long serialVersionUID=longnumber;
}Now assume an instance of A is written to a stream, to a file.
Some time later the skeleton of class A is changed. Let's say this:
class A implements Serializable {
  int a, b, c;
}As you can see there's a new variable named c. If one tries to read in the old (previous) serialized object A (old class) it fails. Quite obvious as a normal readObject() does expect a c variable, but does not get one.
Now my question and I hope someone can give a clear explanation (or some reference or specification) on how to solve this.
One way I found so far is to implement custom readObject() and writeObject() methods in a serialized class. By keeping a version in the class, I can distinguish whether I read and older version or a newer version of the class, if the first is the case I map the old data to new data. A serialid is provided now as well, the same as the old one. However one gets methods like this in class A for example:
class A implements Serializable {
  private static final long serialVersionUID=longnumber;
  private int version = 2;
  private int a, b, c;
  private void readObject(ObjectInputStream in) throws ... {
    int version = in.readInt();  // Which object do we have? Old or new one?
    if(version == 1)
       readVersion1(in);
    else
       readVersion2(in);
  private void readVersion1(ObjectInputStream in) throws... {
    a = in.readInt();
    b = in.readInt();
    c = 0;  // Default value as the old class did not have the c datamember. Just set it to 0
  private void readVersion2(ObjectInputStream in) throws ... {
     a = readInt();
     b = readInt();
     c = readInt();
  // writeObject is skipped, that one is quite obvious
}As you can see the code is getting quite cumbersome (imagine you have much more variables,objects etc). Is there a better way perhaps? Even when classes change internally (new variables, new methods etc).
And when exactly do you need to generate that serialID of a class. As soon as the first version of that class is ready to go and be used?
Another question is, do the standard objects in the java library change (String, Integer..) often in later versions. And if so, what can one do to still be able to read old-compiled code (with older JDK) in new JDK versions?
I hope someone can point me at some good documentation about it, or perhaps provide a clearer view.
Thanx in advance!
Martijn

Answer 1

Hi,
This is an interesting topic and one that I am still experimenting with. But I think you are trying to control too much yourself. Serialization should be, as much as possible, automatic even with versions. Have you looked at the jdk1.4 docs?
j2sdk-1_4_0-beta3-doc/docs/guide/serialization/spec/version.doc.html
This gives a list of compatible and incompatible changes to a class. If you have any incompatible changes then you will need to use the Externalizable interface instead, and then code pretty much as in your example. Compatible changes seem to be handled by the Java libraries themselves.
However nowhere have I found documentation of how the version is determined.
Terry