...
Classes that implement Serializable
without overriding its functionality are said to be using the default serialized form. In the event the class changes, byte streams produced by users of old versions of the class become incompatible with the new implementation. Programs must maintain serialization compatibility during class evolution. An acceptable approach is the use of Therefore, serializable classes that rely on the default serialized form cannot be evolved without compromising compatibility.
To enable compatible evolution of a serializable class, developers must use a custom serialized form, which relieves the implementer of the necessity to maintain the original serialized form and the corresponding version of the class in addition to the newly evolved versionis more flexible than a default form. Specifically,
- use of a custom form severs the dependence of the stream format on the code of the implementing class, and
- the code generated for deserializing a custom form can handle compatible deviations from the serialized form, like extra fields.
As a result, developers need neither maintain the earlier version of the code nor explicitly support the original serialized form.
Note that compliance with this rule, while necessary, is not sufficient to guarantee compatible evolution of serializable classes. For a full discussion of comptabile evolution of serializable classes, see the Java Object Serialization Specification (version 6), Chapter 5: Versioning of Serializable Objects.
Noncompliant Code Example
This noncompliant code example implements a GameWeapon
class with a serializable field called numOfWeapons
and uses the default serialization serialized form. Any changes to the internal representation of the class can break the existing serialized form.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ba3f21719bac5f5e-2ffc55c0-4f99448d-8c70a09e-aea2822872c737f5bbdf65f4"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. References#API 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="70a51a8b092cdb6d-05947e5c-45494d3e-a220a058-9ef0b165d6b62f5241fffa1b"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. References#Bloch 08]] | Item 74, Implement serialization judiciously | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f0f345f4dc7f53e5-c661ccab-4e994a2d-968c869e-6e952e2c8b9e4564c681e0e5"><ac:plain-text-body><![CDATA[ | [[Harold 2006 | AA. References#Harold 06]] | 13.7.5, | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="96841795239f3cd3-0f151056-4951420d-9c599af7-d40eb9e1e3035c37a33894d6"><ac:plain-text-body><![CDATA[ | [[Sun 2006 | AA. References#Sun 06]] | Serialization Specification, 1.5, Defining Serializable Fields for a Class, and 1.7, Accessing Serializable Fields of a Class | ]]></ac:plain-text-body></ac:structured-macro> |
...