Re: Tidy up class/type naming?

[Per Bothner <per at bothner dot com>]

Jim White wrote:
> Doing this back-to-back string substitution of '.' <-> '/' is kind of ugly.

Yes, but we're stuck with it.  This is not Kawa specific.  Sun's JVM
does this too: The "mangled name" of class as it appears in a class-file
is different from the class name used by reflection.  The class
file contains "java/lang/String" in a Class literal, and uses
"Ljava/lang/String;" in method "signatures", even though
String.class.getName() returns "java.lang.String".

> How about changing ArrayType's use of getName to be the Java class name 
> ("[elementClassName") instead of the Kawa's "display name" 
> ("elementClassName[]")?

This is a separate issue: JDK maps the '/' in mangled names to '.', but
it doesn't de-mangle array names - except for the '/' -> '.' incomplete
mapping.  So String[].class.getName() is "[Ljava.lang.String;", but it
should be "java.lang.String[]", while the mangling in the class file is
[Ljava/lang/String;".  This is of course pretty lame.

> That way the meaning of the name is consistent 
> between Kawa and Java and getReflectClass could just use getName.

Why?  What is the benefit of being consistent with something broken?
Is there any compatibility advantage?  Note we already need to
distinguish java.lang.Class and gny.bytecode.Type because the former
is insufficient for a compiler/assembler/disassembler.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/