Updated JEP: nestmates

[forax at univ-mlv.fr]

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

> On 13/04/2017 9:16 AM, John Rose wrote:
>> On Apr 12, 2017, at 3:00 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>> This JEP is not about the JVM providing a way to add a new member to the nest,
>>> so if a language (stupidly you may say) allow to dynamically add a new member to
>>> a nest, the runtime of that language still needs lookup.in().
>>
>> Good point, thanks.  I removed that bullet item.  (Also tidied a few other
>> bits.)  — John
> 
> If lookup() now provides access to nest members (which it does) then I
> would expect it to provide access to the newly added member as well.

Lookup will be upgraded to provides 'nest access' to members defined as nestmates.
But as specified by this JEP, the nestmate relationship has to be set up before classloading time:
- once a nest-top is loaded you can not add another nest member,
- once a type is loaded, it can not be part of a nest afterward.

So nestmates is not a dynamic relationship.

If i want to have dynamic nests at runtime, i can not use nestmates,
but i can *simulate* them, by creating a Lookup on a nest-top (or any other nest members) and using Lookup.in() to see it as a Lookup of a nest member.
So Lookup.in() do not provide exactly the same feature as nestmates, thus it should not be deprecated/demoted. 

> 
> David

Rémi