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

David Holmes david.holmes at oracle.com
Mon May 21 07:29:08 UTC 2018


On 21/05/2018 5:09 PM, Alan Bateman wrote:
> On 21/05/2018 06:57, David Holmes wrote:
>> :
>>
>>> - Can Class::getNestMembers specify if it runs the class initializer 
>>> of any classes that it loads? Less of an issue for getNestHost as the 
>>> host is likely loaded already.
>>
>> None of these methods specifically or intentionally initialize any 
>> classes. A class will be loaded if needed but that is all. The only 
>> Class methods that refer to class initialization are the forName() 
>> variants. I don't see that the nest related methods should do any more 
>> or less in this regard than any other Class methods that may require 
>> classes to be loaded.
> It returns an array of Class objects so it's potentially loading and 
> linking a number of classes, a bulk Class.forName to some extent. I 
> don't think it does any harm to make it clear that it does not run their 
> class initializers. There are other methods where this could be clearer 
> too but that is outside of this feature.

If we're going to raise the bar here then I would prefer to do that to 
all methods at a later time rather then requiring these new methods to 
set a new standard. getClasses(), getDeclaredClass(), getInterface() etc 
all return arrays of Class objects (the same ones as getNestMembers() in 
some cases!) without saying anything about loading versus linking versus 
initialization. The new API was modelled on the existing ones.

Thanks,
David
-----

> -Alan


More information about the core-libs-dev mailing list