Serialization and serialVersionUID
Those of us who are already faced with problems of Java object serialization, know that it is important to specify the attribute static serialVersionUID on serializable classes to allow two applications to continue to be able to exchange data although they have slightly different versions of the classes in question.
Indeed, when an object is serialized, Java starts sending the stream the name of its class and its serialVersionUID. When the object is deserialized from the stream, load the Java class and then verifies that the serialVersionUID corresponds to that in the stream. When not explicitly specified, the serialVersionUID is computed from the characteristics of the class. Most modifications of a class changes the serialVersionUID so calculated. (I have long believed that changes in the implementation of a method did not influence this calculation. I was wrong, some changes, like using the notation <classname>. Class have side effects with certain compilers can change this calculation)
So I thought until recently that two versions of a given class could not be compatible for serialization java if their serialVersionUID (specified or calculated) was the same. (This is easily verified with the utility of serialver jdk)
. . . → Read more: Who said serialVersionUID was mandatory?
