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

[Peter Levart]

Hi,

I'm just an observer of this conversation, but I think I may have 
something to add...

On 10/1/19 6:08 AM, Mandy Chung wrote:
>
>
> On 9/30/19 8:01 PM, John Rose wrote:
>> On Sep 27, 2019, at 3:46 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 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.
>> +1
>>
>>> 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.
>> This is wrong, I think.  The asymmetry between nest host and nest 
>> members is an artifact
>> of the static structure of the class file attributes (NH/NMs) and not 
>> semantically significant
>> to access control (after validation).

I agree. Every member of a nest should have equal permissions. Promoting 
NH to be more "equal" than the rest during runtime is wrong. It is wrong 
also because of another aspect. There has been talk about 
Class.getNestHost() being "dynamic", but Class.getNestMembers() to be 
"static" only. And there was a dilemma of whether to return itself in 
the Class.getNestMembers() for hidden classes.

I think there is no need to return hidden classes in the list of nest 
members even for nests that consist of hidden class(es) only. I think 
that even Class.getNestHost() should be "static" only. Imagine a 
situation where a hidden class HC1 is defined in it's own nest. Then 
this HC1 is used as a LC in a Lookup to define another hidden class HC2 
to be part of this nest (HC1, HC2). What should HC2.getNestHost() 
return? If it returns HC1, then HC2 is effectively preventing HC1 to be 
unloaded.

But this is of course moot since what is the purpose of a nest 
consisting of hidden classes only if they can not refer to each other 
symbolically. Anyway, if above situation can be constructed, then there 
is a problem. Would it make sense to only allow multi member nests if 
they consist of at least one normal named class? Such nests always have 
a named nest host, so Class.getNestHost() never returns a hidden class 
different from this. If we only have nests consisting of:

1 - at least one named class; or
2 - a single hidden class

Then also Class.getNestMembers() could be "static" and simply return an 
empty array for 2nd type of nests - this can always be interpreted as a 
singular nest in program logic. But if it returns an array with one 
member - this, it is also OK considering that it does not hold any other 
hidden class accessible. It is just that is is not "consistent".

Regards, Peter