Updated JEP: nestmates

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Rémi Forax" <forax at univ-mlv.fr>
> Cc: "David Holmes" <david.holmes at oracle.com>, valhalla-dev at openjdk.java.net
> Envoyé: Jeudi 13 Avril 2017 19:25:50
> Objet: Re: Updated JEP: nestmates

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

i've forgotten that. 

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

so lookup.defineClass can ask the VM to create a new nest if none exists or add a member to an already existing next. 

> Lookup.in must track all this, and so will the native access logic of the JVM.

Only adding things will work i suppose. 
Perhaps java.lang.instrument can be updated to allow the same kind of operations. 

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

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

> — John

Rémi