JNI in GCJ 3.2 for Win32

[Ranjit Mathew <rmathew at hotmail dot com>]

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/