This rule raises an issue on a non-transient and non-serializable field within a serializable class, if said class does not have `writeObject` and `readObject` methods defined.
By contract, fields in a `Serializable` class must themselves be either `Serializable` or `transient`.
Even if the class is never explicitly serialized or deserialized, it is not safe to assume that this cannot happen.
For instance, under load, most J2EE application frameworks flush objects to disk.
An object that implements `Serializable` but contains non-transient, non-serializable data members (and thus violates the contract) could cause application crashes and open the door to attackers.
In general, a `Serializable` class is expected to fulfil its contract and not exhibit unexpected behaviour when an instance is serialized.
How to fix this issue depends on the application's needs. If the field's value should be preserved during serialization and deserialization, you may want to make the field's value serializable.
If the field's value does not need to be preserved during serialization and deserialization, mark it as `transient`. The field will be ignored when the object is serialized. After deserialization, the field will be set to the default value corresponding to its type (e.g., `null` for object references).
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 `writeObject` and `readObject`. These methods can be used to properly (de-)serialize an object, even though it contains fields that are not transient or serializable. Hence, this rule does not raise issues on fields of classes which implement these methods.