Updated JEP: nestmates

[David Holmes]

On 13/04/2017 8:51 PM, forax at univ-mlv.fr wrote:
> ----- 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.

Sorry there are too many missing pieces here for me. What does a 
"simulated" nest-mate even mean? What did you introduce, where and how? 
And what access are you expecting to have to what, and how is that 
access being allowed ???

David

>
> Rémi
>