The Two Types of Versioning Problems

This is very good from a bandwidth and network latency point of view. But it can also be somewhat problematic. Suppose, for example, B implements load balancing. Since B isnt involved in the A to C communication, it has no direct way of knowing whether A is still using C , or how heavily. Well revisit this in Chapt er 16 and Chapt er 17 , when we discuss the distributed garbage collector and the Unreferenced interface.

10.5 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 dont 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.

10.5.1 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 Figur e 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 second type of version problem arises from local changes to a serializable class. Suppose, for example, that in our bank example, we want to add the possibility of handling different currencies. To do so, we define a new class, Currency , and change the definition of Money : public class Money extends ValueObject { public float amount; public Currency typeOfMoney; } This completely changes the definition of Money but doesnt change the object hierarchy at all. The important distinction between the two types of versioning problems is that the first type cant really be repaired. If you have old data lying around that was serialized using an older class hierarchy, and you need to use that data, your best option is probably something along the lines of the following: 1. Using the old class definitions, write an application that deserializes the data into instances and writes the instance data out in a neutral format, say as tab-delimited columns of text. 2. Using the new class definitions, write a program that reads in the neutral-format data, creates instances of the new classes, and serializes these new instances. The second type of versioning problem, on the other hand, can be handled locally, within the class definition.

10.5.2 How Serialization Detects When a Class Has Changed