Nest host validation vs NestHost attribute performed by Lookup::defineHiddenClass
mandy.chung at oracle.com
Tue Oct 1 06:04:32 UTC 2019
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