Updated JEP: nestmates

[John Rose]

On Apr 13, 2017, at 9:41 AM, forax at univ-mlv.fr wrote:
> 
> My first email in that thread was about saying to John that nestmate attributes are a compile-time/loading time mechanism so it can not replace all the use cases of Lookup.in().

Once loaded, the nest is a "live" JVM entity, and as such could be modified by an appropriate API.

In fact, we are reserving the private mode from Lookup.defineClass to mean exactly this:  Load a dynamically defined class into a pre-existing nest.

Even more, a class which is not part of a nest can become one (the top, I suppose), when Lookup.defineClass injects a nestmate into it.

Lookup.in must track all this, and so will the native access logic of the JVM.  In fact, for compatibility, it must also track InnerClasses attributes.  (Yes, yuck.)

(David, dynamic nest extension is a likely feature of Lookup.defineClass; it is not part of the base nestmate logic.)

— John