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

[Remi Forax]

----- Mail original -----
> De: "Peter Levart" <peter.levart at gmail.com>
> À: "mandy chung" <mandy.chung at oracle.com>, "John Rose" <john.r.rose at oracle.com>, "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Dimanche 12 Avril 2020 13:37:17
> Objet: Re: java.lang.constant.ClassDesc and TypeDescriptor for hidden class??

> On 4/8/20 11:46 PM, Mandy Chung wrote:
>>
>> Let's call this option c' as it's a modification to option c.  I want
>> to use `123Z` as a suffix example to indicate the significance of the
>> location of ';'.
>>
>> Option c:  `Lfoo/Bar.123Z;`
>> Option c': `Lfoo/Bar;/123Z`
>>
>> If someone creates a MethodType with parameter types of a hidden
>> class, boolean and int, descriptorString() produces:
>>     `(Lfoo/Bar;/123ZZI)V`
>> vs
>>     `(Lfoo/Bar.123Z;ZI)V`
>>
>> ';' can help splitting the parameter descriptors properly in option c
>> that may benefit any error reporting whereas any error message to
>> report for option c' will have to include the entire string.
>>
>> Option c' has the nice property to retain the type descriptor of the
>> original bytes by appending a suffix.  On the other hand option c may
>> produce a human readable string that can be parsed easily e.g. to
>> indicate how many parameter types in this descriptor string.
>>
>> I'm uncertain of the impact of migration if any tool assumes ';' is
>> the end character for a reference type (JVM TI agents may be impacted
>> because JVM TI GetClassSignature returns a type descriptor).
>>
>> What are other benefits of c' over c?
>>
>> I'm currently leaning toward option c as the result string of a method
>> type is easier to parse and one fewer form of names (i.e. type
>> descriptor is "L" + CN + ";") where CN is N + "." + S and it's
>> `this_class` name of `newBytes` from which the hidden class is derived.
> 
> The problem is not that 'c' is easier to parse, but that 'c`' is not
> parsable at all. Do we really want unparsable method descriptors?
> 
> If the problem is preventing resolving of hidden class names or
> descriptors, then it seems that making the method descriptors unparsable
> is not the right place to do that.

I agree with Peter,
throwing an exception is better, there is no way to encode a hidden class in a descriptor because a hidden class has no name you can lookup,
if the API return an unparsable method descriptor, the user code will throw an exception anyway.

> 
> Regards, Peter
> 

Rémi

>>
>>> Yes, it would be even simpler to throw an exception from
>>> `Class::descriptorString` if the class is a HC.  But I think
>>> that’s *too simple*, because it makes `descriptorString`
>>> useless as an input to any class’s `toString` method.
>>> I think that would be a mistake, in the long run.  String
>>> producing methods are very useful for user output and
>>> having them throw (or return null which is about as
>>> surprising) is a sharp edge for anybody using them for
>>> user output.  I could be wrong about that, and if the rest
>>> of y’all are sure I’m wrong about that, go ahead and
>>> throw an exception.  I’ll reserve the right to say “I told
>>> you so” when the appropriate time comes.
>>>
>>> — John
>>
>> OK.   I take the first pass on the spec.
>> `java.lang.invoke.TypeDescriptor::descriptorString` may produce an
>> invalid descriptor string.  This version implements option c but it's
>> very easy to switch to option c' (2-line change).
>>
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/specdiff/overview-summary.html
>>
>>
>> webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/8242013/webrev.01/
>>
>>
>> Class::getName             `foo.Bar/123Z`
>>
>> Option c:
>>   Class::descriptorString  `Lfoo/Bar.123Z;`
>>   MethodType::descriptorString  `(Lfoo/Bar.123Z;ZI)V`
>>
>> If we choose option c', then:
>>   Class::descriptorString  `Lfoo/Bar;/123Z`
>> MethodType::descriptorString  `(Lfoo/Bar;/123ZZI)V`
>>
>>
> > Mandy