Hi Roger,
I would certainly be in favor of a more thorough review of the use of
serialization in the management modules by the serviceability team as
follow-up work.
Cheers,
-Joe
On 10/17/2019 11:29 AM, Roger Riggs wrote:
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
