If I have two classes A and B:
- B inherits from A.
- B implement Serializable.
- A does NOT implement Serializable.
- B defines a serialVersionUID as is best practise.
If there in the future is implemented a breaking change in A and a developer forgets to update the serialVersionUID of B, then there will be serialisation runtime errors for B.
Any good tips and tricks to reduce the risk of this happening?
I did think of some options myself, but they are far from sufficient:
- Add a comment in A about remembering B in case of breaking changes. This is fine but not all developers carefully read the comments where they make changes.
- Make A Serializable too. This is bad because A does not need to be Serializable and it does not fix the issue. A can still implement breaking changes without updating B.serialVersionUID with the same error as effect. The only value is as a reminder about B, a bit like the comment mentioned above.
- Refactor B so it does not inherit from A. This would solve the issue, but seems extreme. There is also a good reason for them to inherit from each other.
The above points becomes even more costly and less likely to have the desired effect, if instead of just A and B then there is a whole chain of inheritance.
Thanks for reading this.
PS: I did try to google this question, but it is tricky to find anything.