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

[Mandy Chung]

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?

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?

Mandy