Updated JEP: nestmates

[David Holmes]

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

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.

Thanks,
David

> — John