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

[Joe Darcy]

Hi Sean,

Amended as requested before pushing; thanks,

-Joe

On 10/8/2019 2:12 PM, Sean Mullan wrote:
> 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
>>>>>