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

[David Holmes]

Hi Paul,

On 22/05/2018 2:39 AM, Paul Sandoz wrote:
> 
> 
>> On May 20, 2018, at 11:32 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>>
>>> 3984     public Class<?>[] getNestMembers() {
>>> I still think not removing dups is a mistake as it could be a source of subtle bugs. But i doubt at this point i can persuade you or others to change it :-)
>>
>> Unlikely. :) Again well-formed programs just won't encounter this and it would penalize all well-formed programs.
>>
> 
> Although those well-formed programs may need to check for dups themselves because they don’t want to rely in implementation details (and they are not aware of the probability of implementations deviating).

I'm quite concerned about your level of concern with "dups". This just 
shouldn't be an issue. While the spec allows for dups javac will never 
produce them - and file a bug on it if it ever does! Similarly for other 
compilers - there is no reason to generate duplicate entries.

Looking through the JVMS and the defined classfile attributes it seems 
to me that the annotations[] of RuntimeVisibleAnnotations (et al) 
doesn't preclude duplicates either. And the bootstrap_methods[] of the 
BootstrapMethodsAttribute. Also look at the parameters[] of the 
MethodParametersAttribute**. Do you agree?

** Which even has an explicit note this is not something a JVM 
implementation has to check.

> Here’s a thought: did you consider caching the nest members in the ReflectionData class? that may be worth doing regardless of dups.

No that was not considered. Caching, as you know, is a space-time trade 
off and we have no data to use to determine whether caching would be of 
any benefit here. To me that would be a future RFE regardless. (And I 
don't expect these introspective nest methods to be used much in any case.)

Thanks,
David
-----

> 
> Paul.
> 
>