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