Versioning Classes
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.
The Two Types of Versioning Problems
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 ...
With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.
No credit card required