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

[Mandy Chung]

On 9/24/19 8:41 PM, John Rose wrote:
> On Sep 24, 2019, at 8:14 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> Hidden classes do not have names and they cannot participate in NH/NM attributes as you noted (2a) in your previous reply.  Why not disallowing defining a hidden class with NH/NM attributes as in the current proposal [1]?
> That’s fine too. But I think it makes the spec a little simpler to say that (a) they are erroneous and (b) they are therefore ignored, rather than adding a special check and a special failure mode, just for HCs.

Yes this is a simplification.  To capture the core reflection API for 
hidden classes:

Class::getNestHost always returns this class if this class is a hidden 
class.  This is good.

Core reflection API presents the static view of what's in the classfile 
(with some exception - Class::getNestHost).

If this class is a hidden class with NM attribute, Class::getNestMembers 
throws LinkageError as the static nest membership validation on each 
member fails - this is consistent when this method is called for an 
ordinary class with bad entry in NM attribute.

Another relevant note to capture here (about `EnclosingMethod` and 
`InnerClasses` attribute):

A hidden class having `EnclosingMethod` attribute and `InnerClasses` 
attribute describing this hidden class as an enclosing class or as an 
immediate member is also erroneous.  (A hidden class should always be a 
top level class and there is no nested hidden class in JLS terms.   If a 
hidden class could be nested, then its enclosing class would need to 
refer to it by name, which is impossible.)

dHC does not do any special checking.  Instead core reflection API such 
as Class::getDeclaringClass, getDeclaredClasses etc will throw an exception.

Mandy