## Why is this an issue?

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;
    }

## Resources

- Vojtech Ruzicka’s Programming Blog: Should I explicitly declare serialVersionUID?