JNI in GCJ 3.2 for Win32

Ranjit Mathew rmathew@hotmail.com
Wed Nov 6 13:15:00 GMT 2002


Hi,

     As proposed earlier, I have built GCJ 3.2 for Win32 again,
this time bypassing the problems created for a crossed-native
build without the "--with-cross-host" flag and therefore
enabling libltdl to be able to use JNI.

The good news is that JNI seems to work, at least for the first
few examples in The Java Tutorial (passing arguments/return-
values back-and-forth between Java/C). It works with a gcj
compiled Java executable as well as with gij interpreted
bytecode. When I'm less sleepy, I'll try funkier stuff. ;-)

However, before proceeding with this, I'd like to point out a
few things:

1. The jni.h header defines JNIEXPORT, JNIIMPORT and JNICALL,
    which map to the 'dllexport', 'dllimport' and 'stdcall' GCC
    "__attribute__" respectively, for native functions with Sun's
    JDK on Windows. This is *not* required by the JNI
    specification and is needed only if we wish to emulate Sun's
    JDK - things work quite fine without them.

2. If we do use the JNIXXX defines, then gcjh *must* use them
    while producing JNI header files. It should output something
    like:

        extern JNIEXPORT rettype JNICALL Java_Foo_bar(...)

    instead of the current:

        extern rettype Java_Foo_bar(...)

3. In particular, if we use the "stdcall" calling convention for
    calling native methods, then the JNI stub generation function
    build_jni_stub( ) in "gcc/java/expr.c" *must* be able to generate
    the correct call. Otherwise the Java program dies with an
    "UnsatisfiedLinkError" for the native method in question.

None of it is really necessary for strict JNI standards compliance -
it is needed merely for emulating Sun's JDK on Windows.

Sincerely Yours,
Ranjit.

-- 
Ranjit Mathew        Email: rmathew AT hotmail DOT com
Bangalore,
INDIA.               Web: http://ranjitmathew.tripod.com/





More information about the Java mailing list