Updated JEP: nestmates
david.holmes at oracle.com
Tue Apr 18 04:48:03 UTC 2017
On 14/04/2017 3:25 AM, John Rose wrote:
> On Apr 13, 2017, at 9:41 AM, forax at univ-mlv.fr
> <mailto: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
> 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.)
Understood - conceptually at least. I was under the perhaps misguided
assumption that there was still a static link between the "anonymous
class" generated and the nest-top to which it would be added, such that
the addition could be validated somewhat (and similarly for the generic
specialization case). I don't know how Lookup.defineClass would validate
a request to inject a nestmate.
> — John
More information about the valhalla-dev