JNI in GCJ 3.2 for Win32

Wed Nov 6 13:35:00 GMT 2002

>>>>> "Ranjit" == Ranjit Mathew <rmathew@hotmail.com> writes:

Ranjit> The good news is that JNI seems to work, at least for the
Ranjit> first few examples in The Java Tutorial (passing
Ranjit> arguments/return- values back-and-forth between Java/C).
FYI there are some test cases in libjava.jni. They are pretty
rudimentary. We can add more tests as needed.
Ranjit> 1. The jni.h header defines JNIEXPORT, JNIIMPORT and JNICALL,
Ranjit> which map to the 'dllexport', 'dllimport' and 'stdcall' GCC
Ranjit> "__attribute__" respectively, for native functions with Sun's
Ranjit> JDK on Windows. This is *not* required by the JNI
Ranjit> specification and is needed only if we wish to emulate Sun's
Ranjit> JDK - things work quite fine without them.
Part of the point of JNI is that it is binary compatible across
releases and Java implementations. So compatibility with Sun seems
pretty important.
We currently don't use these defines anywhere, and in our
implementation they are defined to be empty. Both these things should
be fixed. If you wrote a patch for jni.h, that would be great. If
not, please submit a PR so we don't forget about this.
Ranjit> 2. If we do use the JNIXXX defines, then gcjh *must* use them
Ranjit> while producing JNI header files.
I wrote a patch. I'll check it in soon.
Ranjit> 3. In particular, if we use the "stdcall" calling convention
Ranjit> for calling native methods, then the JNI stub generation
Ranjit> function build_jni_stub( ) in "gcc/java/expr.c" *must* be able
Ranjit> to generate the correct call. Otherwise the Java program dies
Ranjit> with an "UnsatisfiedLinkError" for the native method in
Ranjit> question.
build_jni_stub isn't the real problem. This will always generate an
ordinary call to _Jv_JNIMethod::call. This is the function that has a
problem. It seems to me that we'll need to teach libffi about
stdcall.
Tom