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

[David Holmes]

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