Updated JEP: nestmates

John Rose john.r.rose at oracle.com
Thu Apr 13 17:25:50 UTC 2017

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

More information about the valhalla-dev mailing list