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

[Mandy Chung]

On 4/2/20 9:35 AM, Brian Goetz wrote:
> That a Constable object might be unable to construct a symbolic 
> descriptor is the reason that the `describeConstable` method returns 
> an Optional.  From the spec of Constable:
>
> * Represents a type which is <em>constable</em>. A constable type is 
> one whose * values are constants that can be represented in the 
> constant pool of a Java * classfile as described in JVMS 4.4, and 
> whose instances can describe themselves * nominally as a {@link 
> ConstantDesc}.
>
> Hidden classes are not representable in the constant pool of any class 
> other than the hidden class itself.  Its instances can arguably 
> describe themselves nominally, but those nominal descriptions are of 
> limited usefulness, since they can't be resolved with the aid of a 
> Lookup. [1]
>
> I believe, then, that the right choice is to return an empty Optional, 
> rather than return null or throw an exception.
>

There are two relevant methods in Class:
1.  public Optional<ClassDesc> describeConstable()
       Returns a nominal descriptor for this instance, if one can be 
constructed, or an empty Optional if one cannot be.

No issue with this.

2. public String descriptorString()
     Returns the type descriptor string for this class.

This method returns String, *not* an Optional.  This is the main method 
in question what to do with hidden class.
> Three options:
> a) throws an exception
> b) returns null
> c) returns `La/b/C.0x1234;`

Any other options to handle Class::descriptorString()?

Mandy
>
> [1] Is this correct?  I believe even the Lookup for the hidden class 
> itself cannot resolve the name foo.Bar/0x1234?
>
> On 4/1/2020 8:09 PM, Mandy Chung wrote:
>> Hi Brian, et al,
>>
>> Class is a Constable.  So a Class object for a hidden class can be 
>> asked to yield a ConstantDesc for the hidden class via 
>> Class::describeConstable.  It can also be asked to get the type 
>> descriptor string for the hidden class via Class:descriptorString.
>>
>> A hidden class has no binary name. It cannot be referenced by other 
>> classes nominally. So hidden classes are not the kind of run-time 
>> entities of interest to the bytecode readers and writers.  I propose 
>> no ClassDesc for hidden classes.
>>
>> The relevant APIs need update for hidden classes are:
>> 1. ClassDesc::ofDescriptor
>>
>> The current spec already specifies to throw IAE if the given name is 
>> not a binary name.
>>
>> 2. Class::describeConstable
>>
>> There should be no ClassDesc for hidden 
>> classes.ClassDesc::ofDescriptor returns an empty Optional if it's a 
>> hidden class.
>>
>> 3. Class::descriptorString (inherited method fromTypeDescriptor)
>>
>> Three options:
>> a) throws an exception
>> b) returns null
>> c) returns `La/b/C.0x1234;`
>>
>> `Lookup:defineHiddenClass` specifies the name derived from the 
>> `class` file in the form of:
>>     `N` + "." + <suffix>
>>
>> where N is the binary name indicated by the `class` file and <suffix> 
>> is an unqualified name that is guaranteed to be unique during this 
>> execution of the JVM.
>>
>> But this is not a valid binary name; so not a field descriptor.  This 
>> has a bigger impact to java.lang.constant.
>>
>> None of the options is ideal.  I lean toward (b).  It's rare that a 
>> compiler or other tools using java.lang.constant API will use it on a 
>> hidden class.
>>
>> Please advise.
>>
>> Thanks
>> Mandy
>> [1] 
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte[],boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)
>