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

[David Holmes]

On 26/09/2019 3:26 pm, Mandy Chung wrote:
> 
> 
> On 9/25/19 11:26 AM, Mandy Chung wrote:
>>
>>
>> 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.
>>
> 
> 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?

A hidden class can't have a valid NM attribute as none of the classes 
listed therein could name the hidden class as their NH. Ditto for NH 
attribute. So ignoring those static attributes for a hidden class seems 
fine.

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

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.

David
-----

> 
> Mandy