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

[Mandy Chung]

I have a follow-up question w.r.t. JVMS 5.4.4 access control check (see 
#4 below).  Below #1-3 is a summary with what we agree (please correct 
if anything is incorrect).

1. Hidden classes do not have names and they cannot participate in NH/NM 
attributes.   These attributes in a hidden class are ignored and 
pretending not present.

2. LC::defineHiddenClass defines HNC as a nestmate of LC

LC must be a nest host and full-power lookup which are required to 
authorize to add NHC as a member to the nest of LC.

(A nest member can do LC.in(LC.lookupClass().getNestHost()) to teleport 
to its nest host and call defineHiddenClass.)

2a) validate LC's static NH attribute and error is ignored; LC's runtime 
nest host is determined.
2b) dynamic nestmates are not available for return in Class::getNM
   HNC::getNestHost == LC
   HNC::getNestMembers == LC::getNestMembers

3.  LC::defineHiddenClass defines HC (not added to LC's nest)

3a) no validation of LC's static nest information (as not adding to 
other nest)
3b) HC belongs to a nest of itself; NH/NM attributes are ignored
    HC::getNestHost == HC
    HC.getNestMembers returns 1-element array of HC

HC can add dynamic nestmates to its own nest.

4. nestmate access check specified in JVMS 5.4.4

> 3a. After validation of the asymmetric NH/NM attributes (or after a “bad” NH is thrown away), access control effects of
> nesting structure are applied uniformly across the nest.
>
> 3b. The NestHost has no dynamic distinction from the other nest members, other than a “ceremonial” role in reflection.

In JVMS 5.4.4, "The nest host of C  and the nest host of D are validated 
at access check.  If any exception is thrown, the nestmate test fails 
for the same reason."

The runtime nest host of LC determined in (3a) above will be considered 
here.

LC calls HNC::m after HNC is defined (or HNC calls LC::privM).  This 
access check succeeds as LC and HNC are in the same nest.

However, if LC is accessed by other class D (not a dynamic nestmate) but 
the  nest host has been validated, as the bad NH is thrown away, then 
IAE should be thrown in this case.

If no validation of nest host of C has been performed, then access check 
is the first time attempting the validation, then NCDFE or ICCE is 
thrown instead.  (Note than C and D can be any class).

The access control effects are applied uniformly access the nest while 
in the error case, the exception may be different depends on the timing 
when validation of C's and D's nest host are triggered. This seems to 
bring non-uniformity but may be fine as with error cases?

Mandy
[1] 
https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-September/006396.html