Updated JEP: nestmates

David Holmes david.holmes at oracle.com
Thu Apr 13 11:33:56 UTC 2017

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


> Rémi

More information about the valhalla-dev mailing list