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

David Holmes david.holmes at oracle.com
Mon May 21 07:45:23 UTC 2018

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:

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

More information about the core-libs-dev mailing list