Serialization and Externalization problems

The first non-serializable super-class doesn't have an accessible zero-argument constructor

The first non-serializable super-class doesn't have an accessible zero-argument constructor, as required by section 1.10 of the Java Serialization specification.

Solution: add a zero-argument constructor that is accessible to the first serializable subclass.

Severity level: 1

An Externalizable class doesn't have a public zero-argument constructor

An Externalizable class doesn't have a public zero-argument constructor, as required by section 1.11 of the Java Serialization specification.

Solution: add a public zero-argument constructor.

Severity level: 1

Serializable class containig a non-transient field of a non-serializable type

Serializable class containing a non-transient field of a non-serializable type can make serialization fail if the type is an interface, and is an error if the type is a class.

Severity level: 1

Wrong definition of serialVersionUID

The Java Serialization specification mandates the following declaration for serialVersionUID in section 4.6: private static final long serialVersionUID = 3487495895819393L;

Solution: correct the declaration.

Severity level: 1

Wrong definition of serialPersistentFields

The Java Serialization specification mandates the following declaration for serialPersistentFields in section 1.5: private static final ObjectStreamField[] serialPersistentFields = {new ObjectStreamField("next", List.class)};

Solution: correct the declaration.

Severity level: 1

Non-static inner classes that implement Serializable w/o a serialVersionUID field

The Java Serialization specification strongly recommends in section 4.6 and section 1.10 that inner classes implemention java.io.Serializable use a serialVersionUID field.

Solution: correct the declaration.

Severity level: 1

Non-static inner classes where the enclosing class is not serializable

Serialization will fail for these classes, because the inner class has a hidden reference to the enclosing class, which will fail serialization. Please refer to the Java Serialization specification section 1.10 for a detailed explanation.

Solution: correct the declaration.

Severity level: 1

Using serialVersionUID or serialPersistentFields in a class that is not serializable

Using serialVersionUID or serialPersistentFields in a class that is not serializable is confusing at best, but more likely a programming error. These fields are useless if the class implements java.io.Externalizable.

Solution: remove the field or make the class implement java.io.Serializable

Severity level: 1

Using serialization-related methods in a class that is not serializable

Using readObject, readResolve, writeObject, or writeReplace in a class that is not serializable is confusing at best, but more likely a programming error.

Solution: remove the method or make the class implement java.io.Serializable

Severity level: 1

Using serialization methods in a class that is externalizable

Using readObject or writeObject in an Externalizable class is useless, they will never be invoked.

Solution: remove the method.

Severity level: 1

Wrong method signatures for custom serialization

The method signature of one serialization-related method was not declared as per the Java Serialization specification. The correct signatures are defined in section 2.3-5 and section 1.4-1.6 of the Java Serialization specification.

Solution: correct the declaration.

Severity level: 1

Fields defined in serialPersistentFields that don't exist

This is an obvious oversight while refactoring a class.

Solution: remove the entry from serialPersistentFields.

Severity level: 1

Detect inherited readExternal() and writeExternal() methods when the subclass has additional serializable fields

Each subclass of an Externalizable class that has additional state must implement readExternal() and writeExternal() for proper externalization.

Solution: implement readExternal() and writeExternal().

Severity level: 1