Review Request: Add ClassOption.STRONG and default is unspecified

[Mandy Chung]

On 3/13/20 9:09 AM, Alex Buckley wrote:
> On 3/12/2020 5:43 PM, John Rose wrote:
>> After “doing the math” (in the previous note) I’m with David being
>> skeptical of “unspecified”.  If a JVM implementation maps
>> “unspecified” to STRONG that’s a bug, not a feature ... Only WEAK
>> mode is safe.  So the best we could do is say that “if neither option
>> is specified, then the mode defaults to WEAK”.  But at that point,
>> why have WEAK at all? You only need the token for the non-default
>> setting.
>
> Got it: (i) the default is specified to be WEAK; (ii) the API offers a 
> single enum constant, STRONG, to override the default; (iii) both of 
> the previous clauses apply to hidden classes that are nestmates AND to 
> hidden classes that are not nestmates. Thanks for the enjoyable writeup.
>
> Zooming out, I recommend that the phrase "weak class" be exorcised 
> from JEP 371. It always bothered me that the JEP introduced a concept 
> which sounds first-class, as if it applies widely (inviting "Excuse 
> me, will Lookup::defineClass be extended to take the WEAK option? 
> Where are weak classes in the JVM Specification?" etc), but then 
> pulled the rug by saying it's limited to hidden classes. I think we 
> should frame a hidden class's loose relationship with its 
> deemed-defining loader as just another superpower that 
> Lookup::defineHiddenClass can arrange, along with (say) a hidden class 
> being able to join a nest without holding an entry ticket (i.e. no 
> NestHost attribute). Similarly, if STRONG is specified, then there's 
> no "strong class" to put on a pedestal -- the hidden class's 
> relationship with its deemed-defining loader is exactly the same as an 
> ordinary class's relationship with its defining loader.

This sounds all good to me.

When a hidden class whose relationship with its deemed-defining loader 
is different than that of an ordinary class, Class::getClassLoader 
returns its deemed-defining loader and so does JVM TI GetClassLoader.   
No issue with that.

 From JVM TI perspective, each "loaded" class has one defining loader 
and N initiating loaders.  N is >= 1 in JDK 14 and with hidden classes, 
N becomes >= 0.

For a hidden class whose has either a loose relationship with its 
deemed-defining loader, this is arranged by 
`Lookup::defineHiddenClass`.   From JVM's perspective, a hidden class is 
a "normal" class and I think same applies to JVM TI.  We want hidden 
classes to be debuggable.    JVM TI and JDI etc assume classes are 
always "loaded".

Now, a class can be:
1. a loaded (ordinary) class
2. a hidden class whose has a loose relationship with its 
deemed-defining loader
3. a hidden class whose has a strong relationship with its 
deemed-defining loader - exactly the same as an ordinary class's 
relationship with its defining loader

 From tool's perspective, it wants to find all loaded classes or loaded 
classes initiated & defined by a given loader.   Tools can determine if 
a class is a hidden class or ordinary class using Class::isHiddenClass 
or by its name.   While hidden classes are not "loaded", having JVM TI 
to define new API for this new "API-created-class" and making the tools 
to handle hidden classes using new JVM TI events and new JVM TI APIs 
seem too high cost with little benefit.   Do you see this wrong?

Mandy