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

[John Rose]

On Sep 25, 2019, at 10:26 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> I'd like to clarify this.   NH/NM attributes are ignored for a hidden class.   Should NM attribute be made available for return by reflection API?
> 
> When an ordinary class whose NM attribute contains bad entry, the bad entries are ignored by access control but the bad entries are not dropped and hence Class::getNestMembers throws an exception. Hidden classes can simply follow the same rule rather than and make NM attribute unavailable for return by getNestMembers?

I think a HC should have special logic to report its getNestHost
as the dynamic host, which has nothing to do with the NH/NMs
attributes and everything to do with the arguments to L.dHC.

That is, IMO the reflection API should make it clear when two
classes are in the same dynamic nest regardless of whether
that relation arose from one of them, or both of them, being
defined via the Lookup API.

The getNestMembers must *not* attempt to report dynamically
added nestmates (since that would tend to defeat GC, one of
the reasons for HCs in the first place).

Thus, getNestHost should return up-to-date information about
who is in what nest, while getNestMembers should report only
the initial static configuration.  Or so it seems to me.

— John