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

[Mandy Chung]

Forgot the attachment.

On 9/30/19 10:52 PM, Mandy Chung wrote:
>
>
> On 9/30/19 8: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.
>>
>> 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.
>
> Mandy
>