Review Request: Add ClassOption.STRONG and default is unspecified

[Alex Buckley]

On 3/13/2020 2:49 PM, Mandy Chung wrote:
> 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".

Can you point to the JVM TI and JDI specs which speak of "loaded" 
classes? We may get lucky like we did with the JVM Specification, which 
has always spoken of "creating" a class (not just "loading" it) and thus 
offered a hook to introduce classes which are created without being loaded.

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

I agree we shouldn't double up a bunch of JVM TI methods by introducing 
return-just-the-hidden-classes variants. Since there was a 
performance/overhead concern with WEAK, let me ask a similar question 
here: is there an overhead from making a hidden class debuggable? Might 
a user of Lookup::defineHiddenClass say "No! I don't want this hidden 
class to be debuggable if it costs any bytes at all."

Alex