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

Mandy Chung mandy.chung at
Tue Oct 1 05:52:32 UTC 2019

On 9/30/19 8:02 PM, John Rose wrote:
> On Sep 30, 2019, at 4:14 PM, David Holmes <david.holmes at> wrote:
>> This is conceptually all very nice from the perspective of calling getNestHost and getNestMembers. However, this is somewhat irrelevant when it comes to actual nestmate access checks. The access check (as per JVMS 5.4.4) always involves the statically defined NH as any LinkageError has to be reproducible - one you get a LinkageError trying a specific action you must continue to get the same LinkageError for that action. (The lazy resolution of the NH during access checks really doesn't fit well into this as it implies a class a not 100% linked when it is required to be!)
>> So while we are only interested in allowing access between the generated lambda proxy class and the LC, the actual access check will still need to validate the NH of the LC and if that fails then we can't use our lambda proxy class.
> Two points here:  I think the lambda class D will *always* have access to the LC’s dynamic nest, given a proper definition of “dynamic nest”.
> If the LC has valid a NH or NMs attribute, then that defines a multiple-element dynamic nest, and D has access to that nest, which includes LC.
> (This is true even if some unrelated elements of the NH’s NMs attribute are non-validatable.  Related entries would not be part of the dynamic nest.)
> Now suppose on the other hand the LC or its supposed nest-host has a defect in the relevant NH/NMs attributes, and X is the exception representing this.
> Then LC degrades to a singleton dynamic nest, and attempted access to supposed nestmates of LC by D will fail, since LC is in a mono-nest (dynamically).
> But even so, D has access to LC.  The two of them are a nest of two classes, one dynamic, and one a fallback mono-nest.
> Second, the lambda class D always has access to LC (at least LC, maybe more), only if we jettison the requirement that LC be a NH.

This is good.

Attached is the picture depicting how LC and lambda proxy class 
interacts (I shared with David an earlier version to explain this 
scenario).     It shows an example that LC uses lambda expressions and 
access private members of LC itself only.  It'd be very surprising if NH 
of LC is re-resolved and D access to LC fails.


More information about the valhalla-dev mailing list