Serialization Depends on Reflection Serialization Has a Verbose Data Format

stream.writeIntVERSION_NUMBER; .... } In addition, your readObject code should start with a switch statement based on the version number: private void readObjectjava.io.ObjectInputStream in throws IOException, ClassNotFoundException { int version = in.readInt ; switchversion { version specific demarshalling code. ....} } Doing this will enable you to explicitly control the versioning of your class. In addition to the added control you gain over the serialization process, there is an important consequence you ought to consider before doing this. As soon as you start to explicitly version your classes, defaultWriteObject and defaultReadObject lose a lot of their usefulness. Trying to control versioning puts you in the position of explicitly writing all the marshalling and demarshalling code. This is a trade-off you might not want to make.

10.6 Performance Issues

Serialization is a generic marshalling and demarshalling algorithm, with many hooks for customization. As an experienced programmer, you should be skeptical™generic algorithms with many hooks for customization tend to be slow. Serialization is not an exception to this rule. It is, at times, both slow and bandwidth-intensive. There are three main performance problems with serialization: it depends on reflection, it has an incredibly verbose data format, and it is very easy to send more data than is required.

10.6.1 Serialization Depends on Reflection

The dependence on reflection is the hardest of these to eliminate. Both serializing and deserializing require the serialization mechanism to discover information about the instance it is serializing. At a minimum, the serialization algorithm needs to find out things such as the value of serialVersionUID , whether writeObject is implemented, and what the superclass structure is. Whats more, using the default serialization mechanism, or calling defaultWriteObject from within writeObject will use reflection to discover all the field values. This can be quite slow. Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you dont set serialVersionUID , the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID , on the other hand, the serialization mechanism simply looks up a single value.

10.6.2 Serialization Has a Verbose Data Format

Serializations data format has two problems. The first is all the class description information included in the stream. To send a single instance of Money , we need to send all of the following: • The description of the ValueObject class • The description of the Money class • The instance data associated with the specific instance of Money . This isnt a lot of information, but its information that RMI computes and sends with every method invocation. [ 7] Even if the first two bullets comprise only 100 extra bytes of information, the cumulative impact is probably significant. [ 7] Recall that RMI resets the serialization mechanism with every method call. The second problem is that each serialized instance is treated as an individual unit. If we are sending large numbers of instances within a single method invocation, then there is a fairly good chance that we could compress the data by noticing commonalities across the instances being sent.

10.6.3 It Is Easy to Send More Data Than Is Required