JDK-8281497 : Release Note: Expand checks of javac's serial lint warning
  • Type: Sub-task
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 18
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2022-02-08
  • Updated: 2022-03-24
  • Resolved: 2022-03-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18
18Resolved
Description
The `serial` lint warning implemented in `javac` traditionally checked that a `Serializable` class declared a `serialVersionUID` field. The structural checking done by the `serial` lint warning has been expanded 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. The specific checks include:
* For `Serializable` classes and interfaces, fields and methods with names matching the special fields and methods used by the serialization mechanism are declared properly.
* Additional analagous checks are done for `Externalizable` types as some serialization-related methods are ineffectual there.
* A serializable class is checked that it has access to a no-arg constructor in the first non-serializable class up its superclass chain.
* For enum classes, since the serialization spec states the five serialization-related methods and two fields are all ignored,  the presence of any of those in an enum class will generate a warning.
* For record classes, warnings are generated for the ineffectual declarations of serialization-related methods that serialization would ignore.
* For interfaces, if a public `readObject`, `readObjectNoData`, or `writeObject` method is defined, a warning is issued since a class implementing the interface will be unable to declare `private` versions of those methods and the methods must be `private` to be effective. If an interface defines default `writeReplace` or `readResolve` methods, a warning will be issued since serialization only looks up the super*class* chain for those methods and not for default methods from interfaces. Since a `serialPersistentFields` field must be `private` to be effective, the presence of such a (non-private) field an in interface generates a warning.
* For serializable classes without `serialPersistentFields`, the type of each non-transient instance field is examined and a warning issued if the type of the field cannot be serialized. Primitive types, types declared to be serializable, and arrays can be serialized. While by the JLS all arrays are considered serializable, a warning is issued if the innermost component type is not serializable.

The new warnings can be suppressed using `@SuppressWarnings("serial")`.