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

Brian Goetz brian.goetz at
Thu Apr 2 18:34:31 UTC 2020

Mandy reminded me that descriptorString() is specified to return a JLS 
4.2.3 field descriptor, and so (c) would violate that spec.  I think 
this tilts the table away from (c), even though this string is arguably 
useful (though not clear to whom.)

While the spec for TypeDescriptor doesn't explicitly say "for use in a 
classfile" or "for reflective instantiation", its hard to imagine use 
cases that don't terminate in one of these situations, at which point, 
we're going to fail.  So it is not clear whether we do anyone favors by 
having Class::descriptorString() return something "helpful" that is not 
really helpful.

Given the choice between (a) and (b), well, both are going to result in 
user surprises (though, the spec for TD::descriptorString doesn't 
prohibit returning null.)  Taken together, I think (b) is less awful 
than (a), so I revise my answer to (b).

On 4/2/2020 2:11 PM, Brian Goetz wrote:
>> 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()?
> In this case, (c) seems reasonable; the TypeDescriptor.OfField 
> interface does not say anything about suitability for embedding in a 
> constant pool, resolution with class loaders, etc.

More information about the valhalla-dev mailing list