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

[Peter Levart]

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

Regards, Peter