[Nestmates] RFR: 8199309: [Nestmates] The new Class nestmate methods should have SecurityManager checks

[John Rose]

Thank you.  Ship it!

On Mar 13, 2018, at 2:38 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Here's the final variant:
> 
> http://cr.openjdk.java.net/~dholmes/8199309/webrev.v3/
> 
> This has the previously discussed @throws SecurityException changes, with two additional changes where it still stated "current class" rather than "returned class". (As they are guaranteed to all be in the same package it doesn't make any practical difference but the wording was odd.)
> 
> I've added John's requested assert as a comment, given we can't actually have asserts in Class (the pre-existing ones are actually in a nested class; and now I know why another assert is commented out).
> 
> The tests are left as per previous version.
> 
> Once this is in I'll update the specdiffs and get back to the CSR discussions.
> 
> Thanks,
> David
> 
> 
> On 14/03/2018 1:42 AM, John Rose wrote:
>> On Mar 13, 2018, at 4:18 AM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>> 
>>> Seems I can't. If I add:
>>> 
>>>   Class<?>[] members = getNestMembers0();
>>> +  assert(members[0] == getNestHost0()); // expected invariant from VM
>>> 
>>> then the VM crashes during the build. Seems to hit a recursive attempt to throw an exception from Class.<clinit> then crashes when we exhaust the stack. :(
>>> 
>>> I see other asserts in Class so I'm at a loss to understand why mine causes a problem. ??
>> Darn, another slap from the bootstrap.  Happened to me just the other day with an indy.
>> A tighter assert, the thing I was really hoping for to deal with the security invariant,
>> would be:
>> assert(members.length != 1 || members[0] == this);
>> — John