Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass
david.holmes at oracle.com
Tue Oct 1 06:08:09 UTC 2019
The attachment is likely being stripped by the mailing list. Only John
and I will get it due to direct addressing.
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>
>>>> 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
>>> 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