Webrev request: JDK-8015081

[Jamil Nimeh]

The Subject's readObject can get called in one of two scenarios: When a 
Subject is deserialized and if a SecureSet is deserialized (because of 
the reference to the containing Subject in SecureSet). In the latter 
case, accessing the contents of inputPrincs before deserialization is 
complete causes NPEs (even in valid cases) because the Subject is being 
deserialized before the SecureSet - chicken/egg thing.  I believe I 
could add that simple null check for the object itself back in without 
breaking things, but SecureSet's readObject is now checking the 
contents.  I'll put it back in and re-run the tests to make sure it'll work.

--Jamil

On 06/12/2014 02:40 AM, Wang Weijun wrote:
> Why
>
> @@ -968,14 +963,10 @@
>
>           readOnly = gf.get("readOnly", false);
>   
>           Set<Principal> inputPrincs = (Set<Principal>)gf.get("principals", null);
>   
>           // Rewrap the principals into a SecureSet
>
> -        if (inputPrincs == null) {
> -            throw new NullPointerException
> -                (ResourcesMgr.getString("invalid.null.input.s."));
> -        }
>
>           try {
>               principals = Collections.synchronizedSet(new SecureSet<Principal>
>                                   (this, PRINCIPAL_SET, inputPrincs));
>           } catch (NullPointerException npe) {
>               // Sometimes people deserialize the principals set only.
>
>
> It looks you accept principals being null in serialized form. (Of course, the new object contains a non-null one).
>
> Thanks
> Max
>
> On Jun 12, 2014, at 17:26, Jamil Nimeh <jamil.j.nimeh at oracle.com> wrote:
>
>> Next round: This one incorporates Weijun's comments and cleans up a couple warnings in the test code.
>>
>> http://cr.openjdk.java.net/~weijun/8015081/webrev.05/
>>
>> --Jamil