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

[Peter Levart]

OTOH,

On 10/1/19 12:11 PM, Peter Levart wrote:
> 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
>

...what is the reason for Class.getNestMembers() for not being dynamic? 
It is true that that method throws LinkageError in case the list of 
static members can not be validated. And if a hidden class HC is added 
to a nest whose static members can not be validated (by using a LC that 
is a validated part of that nest), then HC.getNestMembers() will also 
throw LinkageError. But in case when the static members can be 
validated, the returned array could contain all the validated static 
members plus the so far added hidden members which have not been 
unloaded yet. If that is possible to implement, of course. It would work 
similar to WeakReference: If the WeakReference has not been "cleared" by 
GC, the referent can still be obtained.

To make a consistent API, getNestMembers() would have to either "never" 
or "always" return hidden members.

Regards, Peter