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

David Holmes david.holmes at oracle.com
Tue May 22 04:56:02 UTC 2018

Hi Mandy,

On 22/05/2018 2:14 PM, mandy chung wrote:

On 5/21/18 8:41 PM, David Holmes wrote: Class.java

3988 Class<?>[] members = getNestMembers0(); If the above fails with any LinkageError, what is the expected behavior if Class::getNestMembers() is called the second time? will it throw the same LinkageError? Based on the implementation it should throw the same error. We use constant-pool resolution to locate the member classes so if resolution fails then it must continue to fail for the same reason per the JVMS rules. Are you thinking that getNestMembers() should say something about this? That matches what I interpret from the spec.  I just want to confirm.

Okay.

It'd be good to have a test to cover that.

I can add a short loop to the negative testcases for this.

Regarding Alan's and Peter's comment on the spec clarification on primitive type and array type, it is reasonable to take a pass on all reflection APIs and make the text explicit consistently if this class is a primitive type and array type.   I will file an issue to track this.   Class::getModifiers does return the modifier of the component type whereas Class::getEnclosingClass returns null if this class is an array type even if the component type has an enclosing class. Clarification would help developers.

Thanks. I will add the small clarification that Alan requested on getNestHost(). That works too.

Ok. Stay tuned.

Thanks, David

thanks Mandy

More information about the core-libs-dev mailing list