Serialization of objects to
persistent storage presents a potential problem with class version
mismatches. This is because the class itself is not serialized with
the object. Instead, an instance of
that describes the class of the object is
the class name and a version identifier for the serialized object.
This allows the local version of the class to evolve independently of
the serialized data.
It is possible that when an object is deserialized, the class available to the virtual machine is not the same as the one that originally serialized the object. (Remember that serialization stores the data needed to reconstruct the class, but doesn’t store the class’s Java byte code.) As classes evolve, some of the changes that are made will be compatible with earlier versions of the class, and some will not. Generally, compatible changes are those that do not render the serialized data unusable by an earlier version of the class. For instance, adding or removing a method would be a compatible change, since this does not impact the usefulness of the serialized data. The fact that the newer class contains a new method is not relevant to the older version of the class. On the other hand, changing the superclass of a class is not a compatible change because this clearly renders the serialized data useless. After all, the data that was serialized for the old base class can’t possibly be useful to the ...