[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