Why is this an issue?
Fields in a Serializable class must themselves be either Serializable or transient even if the class is
never explicitly serialized or deserialized. For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly
Serializable object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers. In
general a Serializable class is expected to fulfil its contract and not have an unexpected behaviour when an instance is serialized.
This rule raises an issue on non-Serializable fields, and on collection fields when they are not private (because they
could be assigned non-Serializable values externally), and when they are assigned non-Serializable types within the
class.
Noncompliant code example
public class Address {
//...
}
public class Person implements Serializable {
private static final long serialVersionUID = 1905122041950251207L;
private String name;
private Address address; // Noncompliant; Address isn't serializable
}
Compliant solution
public class Address implements Serializable {
private static final long serialVersionUID = 2405172041950251807L;
}
public class Person implements Serializable {
private static final long serialVersionUID = 1905122041950251207L;
private String name;
private Address address;
}
Exceptions
The alternative to making all members serializable or transient is to implement special methods which take on the
responsibility of properly serializing and de-serializing the object. This rule ignores classes which implement the following methods:
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
Resources
