Updated JEP: nestmates

[John Rose]

On Apr 13, 2017, at 10:58 AM, 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 be yuck^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.

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.

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

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.

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.

Make sense?

— John