JDK 14 RFR of JDK-8231368: Suppress warnings on non-serializable non-transient instance fields in java.security.jgss

[Sean Mullan]

I would change "asn1" to "ASN.1" in the comment as that is the more 
common usage of the acronym, otherwise looks good.

Thanks,
Sean

On 10/8/19 1:36 PM, Joe Darcy wrote:
> PS And a revised webrev acting on comments from the JDK-8231262 to use a 
> single class-level @SuppressWarnings when an alternative serial form is 
> implicitly being used:
> 
>      http://cr.openjdk.java.net/~darcy/8231368.1/
> 
> Thanks,
> 
> -Joe
> 
> On 10/8/2019 10:11 AM, Joe Darcy wrote:
>> Hi Sean,
>>
>> Returning to this review....
>>
>> On 9/26/2019 12:35 PM, Sean Mullan wrote:
>>> - Krb5Context.java
>>>
>>> 1394         @SuppressWarnings("serial") // Not statically typed as 
>>> Serializable
>>> 1395         private final EncryptionKey key;
>>>
>>> EncryptionKey is Serializable (it derives from java.security.Key 
>>> which is Serializable). I was wondering why we needed to suppress the 
>>> warning here.
>>
>>
>> Taking a closer look, the field in question is of type
>>
>>     sun.security.krb5.EncryptionKey
>>
>> which is *not* declared to be Serializable:
>>
>> public class EncryptionKey
>>     implements Cloneable {
>>
>> In contrast, the javax.security.auth.kerberos.EncryptionKey class is 
>> declared to be Serializable. Therefore, the @SuppressWarnings on the 
>> field in the initial patch is needed.
>>
>> If the patch looks good, I'll get this pushed.
>>
>> Thanks,
>>
>> -Joe
>>
>>>
>>> --Sean
>>>
>>> On 9/23/19 8:15 PM, Joe Darcy wrote:
>>>> Hello,
>>>>
>>>> Another module, another review request as part of making serial 
>>>> warnings more robust:
>>>>
>>>>      JDK-8231368: Suppress warnings on non-serializable 
>>>> non-transient instance fields in java.security.jgss
>>>>      http://cr.openjdk.java.net/~darcy/8231368.0/
>>>>
>>>> (Related earlier review 
>>>> https://mail.openjdk.java.net/pipermail/security-dev/2019-September/020672.html.) 
>>>>
>>>>
>>>> In this latest review, I included a comment in KRBError.java that 
>>>> its writeObject method uses a different encoding scheme.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>