Dumb Question
I'm trying to build a Kaffe snapshot and am getting a compile error in BigInteger.c: /usr/local/src/kaffe-snap/libraries/clib/math/BigInteger.c:468: undefined reference to `mpz_get_d' This looks like a GMP function. However, I've got that library installed, version 2.0. There's a point release 2.0.2, but I'm sick of downloading stuff right now. Any pointers? -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/
Re: large Class.forName() patch
On that note, here is an updated regression test that takes care
of the case where you have an actual Class name "int" or "I" and
it also checks for / in the name of a class passed to forName().
Mo Dejong
Red Hat Inc.
On Tue, 1 Feb 2000, Godmar Back wrote:
> 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
public class ArrayForName {
public static void testLoadArray() throws Exception {
// Loading by built-in type ID is not allowed
// int != I
// boolean != Z
// long != J
// float!= F
// double != D
// byte != B
// short!= S
// char != C
// void != V
expect("I", "Exception");
expect("Z", "Exception");
expect("J", "Exception");
expect("F", "Exception");
expect("D", "Exception");
expect("B", "Exception");
expect("S", "Exception");
expect("C", "Exception");
expect("V", "Exception");
// Not possible to load by builtin type name
expect("int", "Exception");
expect("boolean", "Exception");
expect("long","Exception");
expect("float", "Exception");
expect("double", "Exception");
expect("byte","Exception");
expect("short", "Exception");
expect("char","Exception");
expect("void","Exception");
// Test loading an array by built-in type id
// int[]== [I
// int[][] == [[I
// boolean[]== [Z
// boolean[][] == [[Z
// long[] == [J
// long[][] == [[J
// float[] == [F
// float[][]== [[F
// double[] == [D
// double[][] == [[D
// byte[] == [B
// byte[][] == [[B
// short[] == [S
// short[][]== [[S
// char[] == [C
// char[][] == [[C
expect("[I", "int[]");
expect("[[I", "int[][]");
expect("[Z", "boolean[]");
expect("[[Z", "boolean[][]");
expect("[J", "long[]");
expect("[[J", "long[][]");
expect("[F", "float[]");
expect("[[F", "float[][]");
expect("[D", "double[]");
expect("[[D", "double[][]");
expect("[B", "byte[]");
expect("[[B", "byte[][]");
expect("[S", "short[]");
expect("[[S", "short[][]");
expect("[C", "char[]");
expect("[[C", "char[][]");
// Array of type void is not allowed
expect("[V","Exception");
expect("[[V", "Exception");
expect("[[[V", "Exception");
// When loading an array using the built-in
// type id, id must be at end of string
expect("[II", "Exception");
expect("[ZZ", "Exception");
expect("[JJ", "Exception");
expect("[FF", "Exception");
expect("[DD", "Exception");
expect("[BB", "Exception");
expect("[SS", "Exception");
expect("[CC", "Exception");
expect("[ZZ", "Exception");
expect("[C;", "Exception");
expect("[C\0;", "Exception");
// [L + Class + ;
// Primitive Class name is not valid
expect("[Lint;", "Exception");
expect("[Lboolean;", "Exception");
expect("[Llong;","Exception");
expect("[Lfloat;", "Exception");
expect("[Ldouble;", "Exception");
expect("[Lbyte;","Exception");
expect("[Lshort;", "Exception");
expect("[Lchar;","Exception");
expect("[Lvoid;","Exception");
// java.lang.Object[] == [Ljava.lang.Object;
// java.lang.Object[][] == [[Ljava.lang.Object;
// java.lang.String[] == [Ljava.lang.String;
// java.lang.String[][] == [[Ljava.lang.String;
expe
Re: large Class.forName() patch
>
> >
> > 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
I like ";int". (But not on that line, getName() should still work.)
> > 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 said nothing of the kind. Since getPrimitiveClass doesn't look the
name up in any hashtable, no PRIMITIVE_INT_MAGIC is needed. But, it
could be changed to do { return forName0(';' + name); }, then the
check for weird primitive classes could be done in java code with
name.charAt(0) == ';'.
> 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?
I'd like to know why the L notation uses dots instead of slashes.
> 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?
Because they aren't bytecode keywords!
Jason
Re: large Class.forName() patch
>
> 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
