java.lang.constant.ClassDesc and TypeDescriptor for hidden class??
brian.goetz at oracle.com
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
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