Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass

forax at univ-mlv.fr forax at univ-mlv.fr
Fri Oct 4 19:28:46 UTC 2019


----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Peter Levart" <peter.levart at gmail.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mercredi 2 Octobre 2019 00:27:49
> Objet: Re: Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass

> Hi Remi,
> 
> On 2/10/2019 8:02 am, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "John Rose" <john.r.rose at oracle.com>
>>> À: "Peter Levart" <peter.levart at gmail.com>
>>> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>>> Envoyé: Mardi 1 Octobre 2019 23:38:31
>>> Objet: Re: Nest host validation vs NestHost attribute performed by
>>> Lookup::defineHiddenClass
>> 
>>> On Oct 1, 2019, at 3:42 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>>>
>>>> ...what is the reason for Class.getNestMembers() for not being dynamic?
>>>
>>> I think you answer your own question in the next sentences:  It’s an expensive
>>> luxury.
>> 
>> it's also unnecessary given that you have Class.isNestmateOf() which works with
>> dynamically added nest members,
>> so instead of using getNestMembers() and re-implement the access checks, you can
>> directly ask the VM if is a class is a nest member of a nest host.
> 
> I'm not sure what point you are making. Using isNestMateOf might be
> useful if you are implementing an access check in Java, but it doesn't
> help with any access check implemented inside the VM.

yes,
i was thinking with my hat of JVM language runtime developer :)

> 
> David
> -----
> 
>> Rémi

Rémi


More information about the valhalla-dev mailing list