Page History

...

After a serializable class is exported, attempts to refactor its code can become burdensome. Specifically, the old serialized form (encoded representation) has to must be continually supported as it is part of the published API. This can be troublesome from a security perspective, as it not only promotes dead code but also burdens the provider who has to eternally maintain the existing codebase.

...

Noncompliant Code Example

This noncompliant snippet code example implements a GameWeapon class with a serializable field called noOfWeapons, and uses the default serialization form. Any changes to the internal representation of the class can break the existing serialized form.

...

Notably, according to the Serialization Specification \[[Sun 06|AA. Java References#Sun 06]\]:

Inner classes can only contain final static fields that are initialized to constants or expressions built up from constants. Consequently, it is not possible to set serialPersistentFields for an inner class (though it is possible to set it for static member classes).

Finally, serialization is easy to get wrong and must consequently be carefully designed.

...

Failure to provide a consistent serialization mechanism across releases can limit the extensibility of classes. If classes are extended, a can of compatibility vulnerabilities may it is possible for compatibility issues to get introduced.

...