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
and
Manager
(a
subclass of Employee
). For the next version of the
application, two more classes need to be added:
Contractor
and
Consultant
.
After careful thought, the new hierarchy is based
on the abstract superclass Person
, which has two
direct subclasses: Employee
and Contractor
. Consultant
is defined as a subclass of
Contractor
, and
Manager
is a
subclass of Employee
. See Figure 10-8.
Figure 10-8. Changing the class hierarchy
While introducing Person
is probably good object-oriented
design, it breaks serialization. Recall that
serialization relied on the class hierarchy to
define the data format.
The ...
No credit card required