JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces

[joe darcy]

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