JDK 14 RFR of JDK-8232442: Suppress warnings on non-serializable non-transient instance fields in java.management.*

Roger Riggs Roger.Riggs at oracle.com
Thu Oct 17 18:29:00 UTC 2019


Hi Joe,

These look ok.

A few of them might be handled by making them transient, but 
SuppressWarnings
calls more attention to them as fields that are being serialized, even 
indirectly.
The presence of a writeReplace method weakens the coupling of the fields 
to the serialized values.

Roger


On 10/16/19 10:31 PM, Joe Darcy wrote:
> Hello,
>
> Quick background, ahead of strengthening javac's -Xlint:serial checks 
> to include more aspects of a Serializable or Externalizable type ( 
> JDK-8160675 ), I've been working through the JDK libraries to review 
> issue found by the upcoming analysis (JDK-8231641).
>
> The latest segment of the libraries to get this treatment is the 
> java.management and java.management.rmi modules:
>
>     JDK-8232442: Suppress warnings on non-serializable non-transient 
> instance fields in java.management.*
>     http://cr.openjdk.java.net/~darcy/8232442.0/
>
> The forthcoming warnings were generally suppressed using
>
>     @SuppressWarnings("serial")
>
> paired with an explanatory comment. Common comments are
>
>     // Not statically typed as Serializable
>
> which states the cause of the general warning and
>
>     // Conditionally serializable
>
> which is used for collections or collection-like objects that are 
> designed to be serializable if and only if their contents are.
>
> An Externalizable class is required by the spec to have a no-arg 
> constructor. Two Externalizable classes in this review do *not* have 
> such a constructor. The classes have both been in the platform for 
> many years and I just suppressed the warning rather than adding the 
> constructors.
>
> Thanks,
>
> -Joe
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20191017/3a057ac8/attachment.html>


More information about the serviceability-dev mailing list