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

[David Holmes]

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.

> 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.
> 
> 
>