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

[John Rose]

On Sep 25, 2019, at 11:54 PM, David Holmes <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.

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.

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.

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.