large Class.forName() patch

[Godmar Back]

> 
> Jason Baker wrote:
> > ./developers/fixup.c:    addSymbol("_Jv_intClass", CLASS, "int", "", "");
> 
> That code is actually commented out already.  Godmar will have to
> chime in on its intent.
> 

At first, I thought I just fake the java::lang::Class _Jv_intClass structure
as a big bss symbol.  Then I realized this doesn't work, and the structure
is now defined in gcj-class.c

> > ./kaffe/kaffevm/itypes.c:       initPrimClass(&intClass, "int", 'I', 4);
> 
> I suggest using some completely bogus, yet human-readable name in this
> context.  The primitive types should never be looked up by name, so
> "[int]" or ";primitive int" or ... hmm, looking in the VM spec (for
> invalid name ideas), I noticed actually it says in S2.2 Identifiers:
> "An identifier must not be ... a keyword in the Java programming
> language."  So, maybe a class with name 'int' is bogus....  Something
> that most JVMs don't seem to check, it seems.
> 
> > ./libraries/javalib/java/lang/Integer.java:     final public static Class TYPE = Class.getPrimitiveClass("int");
> 
> As Jason pointed out, this is an internal hack for Kaffe.  The
> argument could just as easily be Class.PRIMITIVE_INT_MAGIC
> 

I think this sounds about right.

gcj still uses the same scheme by giving the primitive classes
internally the names "int" etc.  See DECLARE_PRIM_TYPE in 
libgcj/libjava/prims.cc

So if you changed that, we'd have to map it in gcj/gcj-class.c.
I do remember that I needed the "int" etc. in the class pool for
gcj code to work; I don't remember the details now.  It did fix something.

Note that Class.getPrimitiveClass does not appear to be an exported 
function, but a function that's package-internal to java.lang, presumably
just to implement the Number.TYPE initializations.  I think it may date back
when Kaffe used Sun's classes.zip, which explains the native implementation
of it.

I think Pat is right that the use of "int" in the old kaffe code
in java/lang/*.java and their inclusion in the class pool for gcj 
support are unrelated.

Let me look at Mo's patch more closely and maybe we find something
that will not break the gcj stuff.  I kind of like to keep the primitive
classes in the classpool---this I think is nicer for keeping statistics
on all classes, for instance.

As for the Class.forName() interface, I think it's better to strive 
for 100% Sun compatibility here, which means to not provide backdoor 
ways to lookup primitive classes such as looking up "I" or "int" if 
Sun doesn't.  For instance, I got totally 
confused already when I thought that kaffe could look up "I" before I 
realized that's because I do all my tests in a directory filled with 
A.class, B.class, ..., I.class, ... Z.class files.

That said, I find Sun's implementation of Class.forName horrible.
Why do I have use the L; form in an array but not for simple classes?
It makes no sense.  Of course, the JDK doc also doesn't document it.
And why shouldn't you be able to look primitive classes up by name?

	- Godmar