JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces (original) (raw)

joe darcy joe.darcy at oracle.com
Mon Aug 6 23:16:45 UTC 2018

Hi Sergey,

On 8/6/2018 3:39 PM, Sergey Bylokhov wrote:

Hi, Joe.

On 06/08/2018 14:30, joe darcy wrote: Even if currently less commonly used, I think "ineffectual" better captures the intention of what I want to convey in the comment than "ineffective." Can you please clarify this: what does it mean "ineffectual" in this context? why we need to "suppress" them and why these fields cannot be dropped?

A serialVersionUID field is intended to be used to provide the serial hash of a class both to avoid the cost of its computation at runtime and to provide cross-version serial stability in the face of innocuous changes to the class. The serialVersionUID of an interface type is not used in the serialization machinery. The names of interfaces are used however. Therefore, a serialVersionUID field on an interface does not have the effect one would assume it has, namely altering the behavior of serialization. In that sense, these field declarations in interfaces are ineffectual.

I'm working on expanding the checks done by "javac -Xlint:serial", including flagging these and other ineffectual serialization coding patterns. I've pushed a number of related cleanup fixes earlier in JDK 12 (JDK-8208060, JDK-8207751, JDK-8208782, etc.). Much of the JDK code base is compiled using "-Xlint:all -Werror", meaning that if the set of checks is expanded and new warnings are generated, the build will fail. While it would be possible to exclude the expanded serial check from the build, I'd prefer to address the serial issues instead.

Since the files modified by  JDK-8209024 are pre-JDK 9 interfaces, their static serialVersionUID fields are public fields, meaning they are part of the interfaces' contract. Therefore, the fieldscannot just be removed per our usual compatibility policy, unlike, say a private field in a class. For that reason, I think it is reasonable to suppress the (future) serial warnings for these fields, rather than to remove the fields. I wouldn't oppose the effort if someone else wanted to deprecated these fields for removal and then remove the fields in a future release, but I don't think the cost/benefit of that particular route is justified.

HTH,

-Joe

More information about the core-libs-dev mailing list