Providing a serialVersionUID field on Serializable classes is strongly recommended by the Serializable
documentation but blindly following that recommendation can be harmful.
serialVersionUID value is stored with the serialized data and this field is verified when deserializing the data to ensure that the
code reading the data is compatible with the serialized data. In case of failure, it means the serialized data and the code are not in sync and this
fine because you know what’s wrong.
When the serialVersionUID is generated by an IDE or blindly hard-coded, there is a high probability that one will forget to update the
serialVersionUID value when the Serializable class is later enriched with additional fields. As a consequence, old
serialized data will incorrectly be considered compatible with the newer version of the code creating situations which are hard to debug.
Therefore, defining serialVersionUID should be done with care. This rule raises an issue on each serialVersionUID field
declared on classes implementing Serializable to be sure the presence and the value of the serialVersionUID field is
challenged and validated by the team.
Noncompliant code example
public class Foo implements Serializable {
private static final long serialVersionUID = 1;
}
public class BarException extends RuntimeException {
private static final long serialVersionUID = 8582433437601788991L;
}
