Updated JEP: nestmates

[David Holmes]

On 15/04/2017 6:00 AM, John Rose wrote:
> On Apr 13, 2017, at 10:58 AM, forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr> wrote:
>>>  In fact, for compatibility, it must also track InnerClasses
>>> attributes.  (Yes, yuck.)
>>
>> I do not think it's a good idea.
>> I suppose it depends if nestmates have their own reflect API or not.
>> If you can access to nestmates using reflection, i suppose code that
>> uses InnerClasses (Class.getClasses()) can be updated to take care
>> about nestmates.
>
> To be clear, I am not proposing that innerclasses and nestmates are
> to be confused by reflection or the JVM or JLI. (Such confusion
> would beyuck^4.)
> They are different things altogether, at the JVM level, different
> expressions of source-level structure.
>
> The reflection API for nestmates needs to be new. (Something like
> Class.getNestTop, Class.getNestMembers.) The existing reflective
> machinery for Class.getDeclaredClasses, Class.getDeclaringClass,
> etc., needs to stay exactly the same, for compatibility. It provides
> much more structural information than nestmates ever could.

A reflection API for nestmates has not formed part of the investigation, 
or implementation, to date. We should add this to the JEP if we do 
intend to add one.

> Lookup.in uses the InnerClasses attribute today, for purposes of
> deciding private access within a source-level nest of classes (and
> injected code). But if the new kind of information is present in the
> future, it should ignore the old information it uses today.

FTR currently I've modified things such that lookup() will find nestmate 
private members. I have not intentionally done anything so far with 
Lookup.in() and I don't know what it currently will provide.

> If the new nestmate information is not present, it needs to continue
> doing what it is doing today, for compatibility. (I suppose it could
> also sniff the class file version and mask out InnerClasses for
> up-rev classfiles, but that's not necessary.)

I was planning to make everything related to the use of nestmate 
attributes classfile version 54+ dependent.

> For class-files compiled with nestmates turned on, either *both* or
> *neither* of the old InnerClasses and the new nestmate information
> will be stored in the classfile. (Right?) And Lookup.in needs to
> ignore the InnerClasses in that case. Meanwhile, the JVM's internal
> access control logic will also ignore the InnerClasses, as it has
> always done and always will do.

Currently the nestmate work is completely 
independent-of/ignorant-of/agnostic-to anything related to innerclass 
attributes. The two universes are disjoint.

> The net result is that Lookup.in will continue to reflectively model the
> source-level access
> control rules for private members of nested classes, but use the
> upgraded information
> source from the classfile when it is available.

I had thought from previous comments that Lookup.in was effectively 
deprecated wrt. nestmates and that lookup() would provide the needed 
access. I was expecting Lookup.in() to continue to do whatever it does 
today, the way it does it today.

Note I'm not opposing this, just noting it would need to be added to the 
to-do list.

Cheers,
David
-----

> Make sense?
>
> — John