[core-libs] RFR (L): 8010319: Implementation of JEP 181: Nest-Based Access Control

[David Holmes]

On 21/05/2018 5:20 PM, Alan Bateman wrote:
> On 21/05/2018 06:57, David Holmes wrote:
>> :
>>
>>> - I suspect the @throws SecurityException in getNestMembers was 
>>> copied from getNestHost as it uses "returned class" (singular). 
>>
>> It refers to "If any returned class ..." and "that returned class". I 
>> don't see any problematic singular uses - can you elaborate please.
> I see your point but it's hard to read. An alternative would be to make 
> it clear there is a permission check when the nest includes classes 
> other than the nest host (rather than "current class").

But it is the current class that determines the need for the access 
check, so I'm not sure what you mean exactly. ??

The condition:

+         if (members.length > 1) {
+             // If we return anything other than the current class we need
+             // a security check

is an optimization suggested by John based on the fact that otherwise 
we're going to hand back the object the caller already has, so there is 
nothing to be gained by having an additional security check (the check 
is to ensure we don't hand back something the caller shouldn't have 
access to - even then I strain to see how this is possible). Here's the 
original review thread:

http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-March/003955.html

> BTW: Paul brought up the hazard of repeated classes. It it possible to 
> have the nest host repeated here? If so then the implementation will do 
> a permission check even if there are no other members.

I wouldn't call it a "hazard" as such. The spec allows it so that the 
implementation doesn't have to waste time verifying it for the 
99.9999999% of well formed code. So yes it could have the host in twice 
and yes that would trigger the check - but would that matter?

Thanks,
David

> -Alan