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

[David Holmes]

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