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

mandy chung mandy.chung at oracle.com
Tue May 22 04:14:15 UTC 2018



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.  
It'd be good to have a test to cover that.

>> 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.

thanks
Mandy




More information about the core-libs-dev mailing list