JDK-8310821 : Add tests for accidental changes to the serialized form of a class
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io:serialization
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-06-23
  • Updated: 2023-07-13
Related Reports
Relates :  
Relates :  
Description
JDK-8266571 inadvertently added a field to the serialized form of LinkedHashMap; the issue was corrected by JDK-8309882.

This seems like something that could be detected by testing. It would be good to create tests for detecting accidental changes to serializable fields. This would include additions, removals, and changes to names or types of fields, and possibly other changes.

Some of these changes are compatible according to JOSS Chapter 5. The main focus here is to detect accidental changes, even if those changes are compatible.

An issue to be decided is, which classes' serialized forms need to be checked in this way. It could be all serializable classes in the JDK, or only those in java.base, or including or excluding selected modules. For example, many Swing classes are serializable, but release-to-release compatibility isn't guaranteed. It therefore might not be worth including such classes in the test. See the warning at the bottom of the class specification of JComponent:

https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JComponent.html

Comments
Perhaps an internal Annotation on the declaration of the serialVersionUID that indicates that the computed SVUID should match the declared one. There may be cases where the computed SVUID is already different from the declared one, in which case the annotation should provide the computed SVUID. It would be easier to maintain in the same source file with the SVUID than in a separate file that might get out of sync or need separate maintenance.
23-06-2023

Probably the test would use a "golden file" with the current names, serialVersionUIDs, and fields of every serializable class (plus maybe some other stuff if possible) and it would compare the actual values to what's in the golden file. It would fail if a change were made accidentally, like I did with LinkedHashMap. But if somebody deliberately wanted to change the serialized form of some class, they'd also have to update the golden file. The golden file should be something other than a binary file, as binary files are strongly discouraged in the repository.
23-06-2023