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

[Mandy Chung]

On 10/1/19 3:42 AM, Peter Levart wrote:
>
> ...what is the reason for Class.getNestMembers() for not being dynamic? 

A class would have to keep track of the nest members which may be weakly 
referenced.  As you said below, it could be implemented but need to see 
use cases that justify such complexity.

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

HC.getNestHost == LC

If LC has a bad NH attribute, then it should never have NM attribute (a 
class must not contain both NH and NM attribute), then HC.getNestMembers 
== LC.getNestMembers == 1-element array containing LC only.

If LC has a valid NH attribute, then LC.getNestMembers may throw 
LinkageError if LC.getNestHost == H where H contains any invalid nest 
member entry.

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

+1

Mandy