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

[David Holmes]

Mandy will have more to say on this, but to clarify ...

On 27/09/2019 9:02 am, David Holmes wrote:
> On 27/09/2019 4:02 am, John Rose wrote:
>> On Sep 25, 2019, at 11:54 PM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> The spec for getNestMembers states:
>>>
>>> /**
>>>  * Returns an array containing {@code Class} objects representing all 
>>> the
>>>  * classes and interfaces that are members of the nest to which the 
>>> class
>>>  * or interface represented by this {@code Class} object belongs.
>>>
>>> so if the hidden class has been injected into a nest then this would 
>>> simply return hiddenClass.getNestHost().getNestMembers() - which I 
>>> think is what John is also suggesting - and that is what 
>>> JVM_GetNestMembers does. If any of the other purported nest members 
>>> are bad then this will throw an exception as normal.
>>>
>>> We may have to clarify the wording if dynamic members are not to show 
>>> up ... though perhaps the dynamic member being asked the question 
>>> should show up?
>>>
>>> If the hidden class was not injected into a nest then this gets a bit 
>>> messy if the current class is not returned as the sole nest member of 
>>> its own nest.
>>
>> This is reasonable.  I think we all agree that getNestHost should be 
>> accurate, even if it is derived from a dynamic Lookup call instead of 
>> a static attribute.
>>
>> And we should not attempt to dynamically update the getNMs list of a 
>> class just because one or more HCs have been attached to its nest, via 
>> the Lookup API.
>>
>> To me this suggests that getNMs is solely static and getHC is 
>> additionally dynamic.
> 
> Yes all agreed.

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.

David
-----

>> There are two questions about getNestMembers and HCs.
>>
>> 1. In the common case where a HC is in a singleton nest (its own nest) 
>> should it report itself as one of its nest members?  I think “yes”, 
>> since that’s also done when a class has none of the static attributes. 
>>   We make up a fake 1-array for the singleton nest, and this “fixup 
>> rule" applies equally well to HCs and regular classes.
> 
> Yes I agree. (I was initially confusing "a hidden class should not 
> appear in NM list" with "a hidden class injected into a nest should not 
> appear in NM list". A non-NESTMATE hidden class is just like any other 
> top-level class with no NH/NM attributes.
> 
>> 2. If an HC is injected into the nest of another class K, should it 
>> “see itself” in its *own* getNMs array?  Thanks for raising this, 
>> David; I had not considered this bit of mess.  I would prefer “no”, 
>> since that’s a new bit of “fixup logic” to add, but “yes” is OK too.
> 
> "No" is good. getNMs remains the static view of the nest-hosts NM 
> attribute.
> 
> Thanks,
> David
> -----
> 
>> We can say that, unlike getNH, getNMs reports only information 
>> statically derivable at one point, after class loading and before any 
>> dynamic injection of HCs.  Furthermore, I think I’d prefer saying that 
>> the HC making the query doesn’t see itself, but the other choice is 
>> OK.   I prefer to exclude the HC from its own list on the grounds that 
>> HCs should appear in getNMs lists as seldom as possible, since they 
>> don’t “belong” there.  The cost of excluding an HC from its own 
>> mono-nest is probably too high, so put it in its own getNMs as an 
>> exception, but don’t compound the problem by having it peep out of 
>> more complex getNMs lists.  Anyway, that’s my take.
>>
>>
>>