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

[Peter Levart]

On 10/1/19 8:04 PM, Mandy Chung wrote:
>
>
> On 10/1/19 3:11 AM, Peter Levart wrote:
>> 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.
>>
>
> There is no restriction what a hidden class can call, for example, 
> using lambda or method reference, which may call a framework library 
> to generate HC2.  HC1 and HC2 should be unloaded when both classes 
> become unreachable.   Do I miss the issue you tried to point out?

I was trying to point out that a hidden class added to a nest that has a 
hidden nest host class will retain the nest host class (in order to be 
able to return it from getNestHost() method). Which may not be desirable.

>
> (Note that defineHiddenClass takes an enum constant to specify if the 
> hidden is a dynamic nestmate and/or a weak class to specify if it's 
> weakly referenced by the class loader.  In other words, a dynamic 
> nestmate has the same lifecycle as its defining class loader if not 
> specified weak.)

Ok, so suppose the 1st hidden class HC1 is defined in its own nest and 
specified to be weak. Then another hidden class HC2 is defined to be 
part of the same nest, this time specified to not be weak (to be 
retained by the classloader). Because HC2.getNestHost() returns HC1, HC1 
is now "trapped" too, since it has to be retained by the HC2 class to be 
returned by HC2.getNestHost() and therefore can't be unloaded until HC2 
can be.

I'm questioning the purpose of multi member nests composed solely of 
hidden classes. Being part of nest means that you can access private 
members of other nestmates, but how do you access a private member of a 
hidden class from another class if you can not refer to the hidden class 
symbolically? You could perhaps use reflection or MH.Lookup to obtain 
direct MHs. Is that an important usecase?

Regards, Peter

>
> Mandy