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

[David Holmes]

Hi Mandy,

The attachment is likely being stripped by the mailing list. Only John 
and I will get it due to direct addressing.

David

On 1/10/2019 4:04 pm, Mandy Chung wrote:
> 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
>>