Java Enterprise Best Practices

Be Aware of How Externalization and Serialization Differ with Respect to Superclasses

One of the biggest differences between externalization and serialization involves how they handle superclass state. If a class implements Serializable but not Externalizable and is a subclass of another class that implements Serializable, the subclass is only responsible for marshalling and demarshalling locally declared fields (either a method code in the superclass or the default serialization algorithm will be called to handle the fields declared in the superclass).

If, on the other hand, a class implements Externalizable, it is responsible for marshalling and demarshalling all object state, including fields defined in any and all superclasses. This behavior can be very convenient if you want to override a superclass’s marshalling code (for example, this lets you repair broken marshalling code in a library). Implementing Externalizable will let you do so quite easily.

But externalization’s requirement that you explicitly marshal and demarshal superclass state doesn’t really mesh well with inheritance. Either you break encapsulation and let the subclass handle the superclass’s state, or the subclass has to call a superclass method to marshal and demarshal the superclass state. Both options can lead to error-prone code. In the first case, if you add or remove a field in the superclass, you then have to remember to modify the subclass. In the second case, you have to rely on programmer discipline ...