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

[David Holmes]

Hi John,

On 1/10/2019 1:02 pm, John Rose wrote:
> On Sep 30, 2019, at 4:14 PM, David Holmes <david.holmes at oracle.com> 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.

That is what I think we would like to be the case, but at present this 
is not how things play out according to the JVMS. We will have to make 
changes to the specification to allow for this dynamic degradation. 
Those changes will further expose the "rough edges" that exist in 
relation to nestmate access checks, their relationship to the "linked" 
state of a class, and the "memoization" of LinkageErrors.

Cheers,
David
-----

> 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.
> 
> — John
>