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

Joe Darcy joe.darcy at oracle.com
Wed Oct 23 17:27:37 UTC 2019


Serguei or others working directly in java.management, any other 
comments on these changes?

Thanks,

-Joe

On 10/17/2019 3:58 PM, Joe Darcy wrote:
> 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
>>>
>>


More information about the serviceability-dev mailing list