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

[John Rose]

On Apr 16, 2020, at 2:34 AM, forax at univ-mlv.fr wrote:
> 
> We have forgotten MethodType.toMethodDescriptorString() [1], it has to be updated too.

Good catch.

> I still disagree with John, it's fine to use the scheme c' has a name for the Hidden Class. I still think the Java methods that says in their spec that they return a descriptor should return a valid descriptor thus throw an exception if there is a hidden class somewhere in the descriptor so a user has to decide how to handle Hidden Class before calling those methods.

We disagree mainly because I think Class::getName returning a specious but
informative name is a solid precedent, and that it applies to the present case.
There’s always going to be a crack or two in the scheme when (a) unchecked
strings are translated into resolvable names, and even more when (b) unresolvable
entities have to state their names.  The point here is to move the cracks where
fewer people will stumble over them, and those who stumble can recover easily.
Since that’s a judgement call, it’s not surprising there are varieties of opinion.

> Anyway, we should move on that, the patch is fine for me if the javadoc of toMethodDescriptorString is updated too, so let's record that i disagree and move on.

Thank you.

> And for ASM, we have already talked to deprecate any methods that takes a live object in Type (j.l.Class and j.l.r.Method) because it causes surprising classloading loop when ASM is used in a classloader or in an agent, hidden class not having a proper name is another data point in that direction.


Good point.  That’s an example of what I said in the previous email,
about library authors having to make their own choices regarding
HC inputs.

I’m glad we are moving towards better documentation of Class and
MethodType instances which do not have nominal descriptions.
That is a very good side effect of these picky discussions.

— John