JNI bug?

Question

Hi,
I hope this is an OK place to report bugs. The opening message on the forum
points to the website for bug reporting, but that's only about support and
I'm not looking for support, I just want to report a bug (I think).
Anyway. I'm playing with JRocket 7 over Win2K sp3. The version string is:
$ ./java -version
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0)
BEA Weblogic JRockit(R) Virtual Machine (build
7.0-1.4.0-win32-GARAK-20020830-1714, Native Threads, Generational Concurrent
Garbage Collector)
I'm using JNI and though most things seem to work OK with JRocket, I've
found that using JNI to call java.lang.Class.getDeclaredMethods() on any
class object will trigger a Null pointer exception. The attached program
demonstrates this. If you compile it up, and then call it with the full
path to the JVM.DLL then it tries to print the results of listing all the
methods of java.lang.Class. With Sun's J2SDK 1.4.1 (and before), and IBM's
1.2-style JDK, it works fine. Using JRocket it throws a
NullPointerException. I'm using all default options for JRocket.
I'm using the CallObjectMethodA() function with a NULL argument array to
invoke the method ('cos that's what my real code does), but providing a real
non-NULL array, or using the varags form, CallObjectMethod(), makes no
difference.
BTW, I'm finding a few other places where JR's JNI is inconsistent with
Sun's (not necessarily bugs, though I think some are). Should I post them
here ? Or email someone ? Or just keep 'em to myself ;-)
-- chris
[JNITest.zip]

Answer 1

Staffan,
I had a look at this and can confirm
that this is indeed a problem in JRockit. Unfortunately there is no easy
workaround other than calling Class.getDeclaredMethods() from a Javamethod
instead of directly from JNI. Can you explain a bit more about your
application and what you want to achieve?Thank for confirming the bug (which, incidentally also affects the other
get[Declared]{Field/Method/Constructor/Class}[s] methods -- with the
exception of getInterfaces(), for some reason).
What I'm doing is using JNI to drive the JVM from Smalltalk. I'm using
reflection to generate (on-the-fly) wrapper (Smalltalk) classes
corresponding to Java classes and whose instances internally use JNI to
invoke the Java methods, etc. So it's rather important that reflection
actually works ;-)
There's no great difficulty in setting up a forwarding Java class that
invokes the reflection methods of java.lang.Class, and the forwarding
class's methods can be invoked from JNI without problems, so I've been able
to put together a patch that allows my stuff to work over JRockit.
You asked about the other inconsistencies I've found. There are only 3 (now
I've had a chance to analyse what I was seeing a bit better -- not to
mention getting rid of a couple of bugs of my own...). None is especially
important, and they are kind of esoteric too, but FWIW:
The JNI DefineClass() method: Sun's implementation will accept NULL values
for either or both of the name and the class loader. JRockit seems to get
an access violation (this is on Windows) if given a NULL name, and
apparently calls exit() if it is given a NULL class loader. I think that
the Sun behaviour is better since both the name and the classloader are
optional using the Java interfaces.
Given a couple of Java classes:
class Base
Base(int i) {}
Base(boolean b) {}
class Derived
extends Base
Derived(int i) {}
Attempting to use one of Base's constructors as if they were "inherited" by
Derived acts differently on Sun and JRockit. Code like (I'm typing this off
the top of my head):
jclass derived = jnvEnv->findClass("Derived");
jmethod mid = jniEnv->GetMethodID(derived, "<init>", "(Z)V");
jvalue args[1];
args[1].z = true;
jobject new = jniEnv->CallConstructorA(derived, mid, args);
will fail on Sun's VM since the call to GetMethodID() will fail with a
NoSuchMethodError (correctly, I think) whereas JRockit will return a handle
on the constructor with the same signature in the superclass. When that
"inherited" constructor is then used the created object is of class Base,
even though the constructor was invoked on Derived.
Given the following:
class Base { public static int ambiguous = 100; }
interface Interface { int ambiguous = -100; }
class Derived extends Base implements Interface { }
Any reference to Derived.ambiguous from Java will trigger a compile-time
error. However it is legal to do the equivalent from JVM bytecodes (a
getstatic with class="Derived" name="ambiguous" type="I") and is defined (as
I read the spec) to be -100. I.e. the JVM resolves the field reference to
the interface. Under both the Sun and JRockit JVMs that works as expected.
Doing the equivalent from JNI:
jclass derived = jniEnv->findClass("Derived");
jfield fid = jniEnv->GetFieldID(derived, "ambiguous", "I");
jint value = jniEnv->GetStaticIntField(derived, fid);
returns -100 on Sun's JVM (which is what I'd expect), but returns 100 on
JRockit (which I think is wrong).
Like I said, esoteric...
Hope this helps.
-- chris