FYI, augmented javac -Xlint:serial checks coming soon to JDK 18

[Joe Darcy]

Hello,

At present, the -Xlint:serial checks done by javac check that a 
serializable class has a serialVersionUID field and that the field is 
properly declared, with type long and modifiers static and final, etc. 
Besides serialVersionUID, the serialization mechanism recognizes and can 
also use one other field (serialPersistentFields) and five methods 
(writeObject, writeReplace, readObject, readObjectNoData, and 
readResolve). These other entities need to be declared properly to be 
used by serialization as well, but -Xlint:serial does no checks on them.

Changes currently out for review [1] will augment javac's -Xlint:serial 
checking to cover the other field and five methods, along with related 
changes. The overall objective of the expanded serial checks is to warn 
for cases where declarations would cause the runtime serialization 
mechanism to silently ignore a mis-declared entity, rendering it 
ineffectual. Also, the checks include several compile-time patterns that 
could lead to runtime failures. One of those patterns concerns the types 
of instance fields of serializable classes. In summary, if a 
non-transient instance field of a serializable class is declared to have 
a non-serializable type, it may indicate a problem since a serialization 
attempt could fail at runtime. Since enum classes and record classes 
have specialized serialization handling, those kinds of classes have 
customized lint checks compared to general classes. The details of the 
checks are given in a pair of CSRs. [2]

The JDK build enables the serial lint check, among other lint checks, so 
to keep the build working with the warning enabled, the code in the JDK 
must pass the new checks no later than when the augmented checks are 
integrated. The recent subtasks of JDK-8231641 have been updating the 
JDK libraries to comply with the checks for fields with non-serializable 
types in serializable classes. Previous passes over 
serialization-related declarations in the JDK had identified and 
addressed the other categories of warnings (JDK-8207751, JDK-8207816, 
JDK-8203263, JDK-8208060, JDK-
8208782 , …) and no other instances of those were introduced in the interim.

As with the existing serial warnings, the new warnings can be suppressed 
using a @SuppressWarnings("serial") annotation.

Cheers,

-Joe

[1] https://github.com/openjdk/jdk/pull/5709

[2] https://bugs.openjdk.java.net/browse/JDK-8274335
https://bugs.openjdk.java.net/browse/JDK-8274336