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

[David Holmes]

Hi Peter,

On 22/05/2018 6:36 PM, Peter Levart wrote:
> 
> 
> On 05/22/18 02:05, David Holmes wrote:
>>> 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. 
> 
> Javac compiler can misbehave (have bugs) in various ways and produce 
> misbehaving programs, but that doesn't mean that runtime libraries 
> should try all possible ways to work around any imagined compiler 
> misbehavior. I think this is a situation where assert would be 
> appropriate. Unfortunately asserts in j.l.Class are not "allowed" or 

Yeah no asserts in Class itself.

> what? Would it work if assert was issued in some other class? For 
> example in ReflectionData (if it is going to be used for caching anyway)?

If we were to cache in the future then yes it could be a place to check 
for and/or filter duplicates.

Cheers,
David

> Regards, Peter
>