[code-reflection] RFR: Improve JavaType::toString

[Paul Sandoz]

On Tue, 4 Jun 2024 12:39:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Alignment with `Type.toString` is very useful for runtime debugging. I think we should remove `ClassType.toClassName`. We should probably rename the `JavaType.ofString` method to avoid confusion.
> 
> Re. `JavaType::ofString`, it seems to be used:
> 
>     * in both Spriv and Triton examples
> 
>     * in cast/instanceof op parsing, as the parsing code seems to work both with types and strings (not sure that's intended)
> 

Yes, it was intended. Some externalizable operation attributes strings are parsed as types.

> 
> (one option could be to rename `ofString` to `ofExternalString` or `ofSerializedString` or something such.
> 

Renaming seems a good idea, its really just a composition of ExternalizedTypeElement.ofString and the CoreTypeFactory.JAVA_TYPE_FACTORY.constructType. Also we should rename the `ofString` on MethodRef, FieldRef, and RecordTypeRef.

In some cases the string form is used as a short cut to avoid the intermediate ClassDesc form, and we should clean those up.

e.g.,


    static final JavaType TYPE_Triton_Test = JavaType.ofString("oracle.code.triton.TritonTest");


It's sort of a hack to add some test stuff without explicitly resolving the Java type.


> As for `ClassType::toClassName` a couple of consideration:
> 
>     * Given there's generics, and also enclosing types, perhaps a method that just return the name of the class might still make sense (dunno whether we want to call it `toClassName` though). E.g. something that given `MethodHandle$Lookup` just returns `Lookup`. Something like this might be useful as we seem to have logic to subtract the enclosing name from the enclosed one in several places.
> 
>     * `toClassName` is also used by the spirv example, so not sure what kind of compatibility needs to be provided for the example to keep working as expected?

There are also usages in HAT. I think we need to hold back on this for a bit and think some more, and its likely used in a fragile way.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/110#issuecomment-2147890335