Re: GCJ .jar to .so with native method

[Andrew Haley <aph at redhat dot com>]

Joe Hoffert writes:

 > You had helped me very much last month trying to integrate Java and C++
 > using gcj/gcjh. I've run into problems (both using the gcj/gcjh .so
 > approach and the Java Invocation API approach). I can present details
 > about the specific problems but I'm wondering if you knew of problems in
 > general with generating a Java library using JDK 1.5 and then using
 > that .jar file with g++/gcj 4.1.2.
 > 
 > I needed to use both JDK and gcj since the Java source code uses
 > generics which gcj won't compile and I'm using g++ for my C++ compiler.

Ouch.  GCC trunk is much better at this now.

 > I had problems loading and calling the Java library using JDK 1.6 and g
 > ++/gcj and then switched to compiling with JDK 1.5. This got me to my
 > present situation of segmentation errors showing up.

OK.

 > I'm suspecting the mixing of JDK and g++/gcj as a problem area because
 > of the problems I saw using JDK 1.6 and also because of the following. I
 > have C++ code that uses the Java Invocation API to load the Java library
 > and make calls into it. The Java library also has a native method that
 > calls back into C (and then C++).

 > However, I get strange segmentation errors from the JVM with the
 > C++ code that is called back from the Java library. I have the C++
 > code running in its own thread (spawned after the native method is
 > invoked) with the stack trace from the JVM crash showing all C/C++
 > code. I am puzzled why the JVM would crash with a call stack like
 > this. That's why I'm suspecting a larger problem of JDK and g++/gcj
 > not working well together. Do you have experience with these types
 > of problems?

Yeah.  The question is, who created the thread?  If it was created by
C++ then the JVM won't know about it and the gc won't know about it.
This is a Bad Thing, and will lead to tears.

See the manual:

 -- Function: java::lang::Thread* JvAttachCurrentThread (jstring NAME,
          java::lang::ThreadGroup* GROUP)
     Registers an existing thread with the Java runtime.  This must be
     called once from each thread, before that thread makes any other
     Java or CNI calls. It must be called after `JvCreateJavaVM'.  NAME
     specifies a name for the thread. It may be `NULL', in which case a
     name will be generated.  GROUP is the ThreadGroup in which this
     thread will be a member. If it is `NULL', the thread will be a
     member of the main thread group.  The return value is the Java
     `Thread' object that represents the thread.  It is safe to call
     `JvAttachCurrentThread()' more than once from the same thread. If
     the thread is already attached, the call is ignored and the current
     thread object is returned.

 -- Function: jint JvDetachCurrentThread ()
     Unregisters a thread from the Java runtime. This should be called
     by threads that were attached using `JvAttachCurrentThread()',
     after they have finished making calls to Java code. This ensures
     that any resources associated with the thread become eligible for
     garbage collection.  This function returns `0' upon success, or
     `-1' if the current thread is not attached.

What you are doing sounds basically OK, but mixing Java API versions
probably isn't a good idea.  If I were you I'd grab a prerelease gcj
snapshot and use that.  This should give you much better compatibility
with code written for the Java 1.5 API. 

 > I can provide more detail if that's helpful but I want to see if
 > someone else knows of problems mixing JDK 1.5 and g++/gcj 4.1.2
 > before I spend any more time looking into this. Do you know of
 > problems mixing JDK and gcj?

Usually it "just works", but you are trying to do something pretty
complex with this mixture of languages and versions.  I'm surprised it
even links: there are a lot of methods in the Java 1.5 API that are
missing in the version of gcj you're using.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903