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

[Peter Levart]

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.

Regards, Peter

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