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

[Mandy Chung]

This patch looks fine.

Mandy

On 10/23/19 10:27 AM, Joe Darcy wrote:
> 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
>>>>
>>>