Review Request: Add ClassOption.STRONG and default is unspecified

[Alex Buckley]

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.

Alex