Enthuware

If you make changes to the class and if you still want old objects to be successfully deserialized into the updated class objects, you should keep the same value for serialVersionUID.

Student wrote:

If you make changes to the class and if you still want old objects to be successfully deserialized into the updated class objects, you should keep the same value for serialVersionUID.

This is illogical. It implies you can have two versions of a class with different data members, but the same serialVersionUID, and that they can be successfully serialized/deserialized to/from each other. Doesn't that beg the question is to why you need to have a serialVersionUID in the first place? If you can make changes to a class and keep the same id, and it won't break, why bother having an id?

import java.io.*;
class A implements Serializable
{
   public String str = "123";
   //public String ptr = "ddd"; //Uncomment this line later while deserializing
}


public class TestClass {

 public static void main(String[] args) throws Exception {
   A a = new A();
   ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("c:\\temp\\a.ser"));
   oos.writeObject(a);
   oos.flush(); oos.close();

   //Comment the above part and uncomment the below part while deserializing
   /*
   ObjectInputStream ois = new ObjectInputStream(new FileInputStream("c:\\temp\\a.ser"));
   A a = (A) ois.readObject();
   System.out.println(a);
   */
 }
}

Exception in thread "main" java.io.InvalidClassException: A; local class incom
tible: stream classdesc serialVersionUID = -8854535988937765686, local class s
ialVersionUID = -7615702988160566258
at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at TestClass.main(TestClass.java:18)

admin wrote:Not sure how you tested but the following program throws an exception when you try to deserialize:

It is possible to deserialize the older objects into the update class objects even if the original class did not explicitly define the serialVersionUID field.

Well, if the serialVersionUID of the class after changes is same (which can be, if you set it explicitly), then the new field will be left with its default value. If it is different, an exception will be thrown.
You should try it out.

-Paul.

sir_Anduin@yahoo.de wrote:
And this is why answer 5 can´t be right:
because you provide no serialVersionUID, so it will be auto generated and differ from the serialized one, when you add a new field.
This is proven by your example, Paul.

This answer would be correct only, if you provice the same serialVersionUID before and after serialization, but you cant know from thee question.

Or am I missing something here?

thanks

Aleks