java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

[John Rose]

On Apr 15, 2020, at 11:40 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Peter, Remi,

FTR, I am fine with either c or c’.  I suppose I weigh the risks slightly
differently, leading to a slight preference for c’ over c, but I’m very
happy with either, because they allow descriptorString to be dual
use just as Class.getName is dual use.  Adjusting the API docs to make
the distinction between nominally described entities and others
is an excellent step.

In fact, it might be a nice idea (not required though) to link the javadoc
for Class.getName to Class.descriptorString, and note that Class.getName
returns a resolvable name (via Class.forName) when Class.descriptorString
is a valid descriptor—except (oops) for primitives.  This could be a followup
change.

(BTW, are there test cases that cover arrays of hidden-classes, and their
Class.descriptorString and Class.getName?)

> Lois and Harold have given further feedback.   They are concerned with option c's impact to JVM implementations due to this new form of signature whose name is outside the "[;"] envelope  whereas signatures are always inside the "[;]" envelopes since day 1.   Option c'  appears to have a higher compatibility risk not only in existing libraries but probably also VM implementations.

Adopting c over c’ pushes the risk around, out of the JVM and into
user-written code in places like ASM.  The risk is small, so it’s probably
easy to tolerate.  Specifically, if the user-written code calls String.replace
to change ‘/’ to ‘.’ then the distinction of the last dot will be lost.
Such is life.  The resulting spurious class name will almost certainly
not resolve, right?  And it’s the responsibility of the user-written code
to decide (a) whether HC’s are possible inputs, and (b) what policy to
take toward such inputs.

— John