A few pages back, I described the serialization mechanism:
The serialization mechanism automatically, at runtime, converts class objects into metadata so instances can be serialized with the least amount of programmer work.
This is great as long as the classes don’t change. When classes change, the metadata, which was created from obsolete class objects, accurately describes the serialized information. But it might not correspond to the current class implementations.
There are two basic
types of versioning problems that can occur. The
first occurs when a change is made to the class
hierarchy (e.g., a superclass is added or
removed). Suppose, for example, a personnel
application made use of two serializable classes:
Employee). For the next version of the
application, two more classes need to be added:
After careful thought, the new hierarchy is based
on the abstract superclass
Person, which has two
Consultant is defined as a subclass of
Manager is a
Employee. See Figure 10-8.
Figure 10-8. Changing the class hierarchy
Person is probably good object-oriented
design, it breaks serialization. Recall that
serialization relied on the class hierarchy to
define the data format.