Re: GCJ .jar to .so with native method

[Joe Hoffert <jhoffert at dre dot vanderbilt dot edu>]

Hi, Andrew.

You're right that using gcj or g++ to link doesn't matter. The difference
with what I was doing before was the compiler/linker options.

One more question. Is there any advantage to converting a .jar library
to a .so library and using it as opposed to simply using the
original .jar file with the Java invocation API and the JNI to call back
to C++ from Java? I thought I would get a performance increase with
using the .so library but perhaps there are no substantive differences
between the two approaches.

Thanks again for all your help!

-Joe

On Tue, 2007-12-04 at 16:42 +0000, Andrew Haley wrote:
> Joe Hoffert writes:
>  > Hi, Andrew.
>  > 
>  > On Tue, 2007-12-04 at 15:59 +0000, Andrew Haley wrote: 
>  > > Joe Hoffert writes:
>  > >  > Hi, Andrew.
>  > >  > 
>  > >  > On Tue, 2007-12-04 at 15:16 +0000, Andrew Haley wrote:
>  > >  > 
>  > >  > OK. I've attached a zip file with everything that should be needed. The
>  > >  > gcj-commands file simply contains the gcj and gcjh commands I used to
>  > >  > generate the .so library and the .h header files.
>  > > 
>  > > Works for me:
>  > > 
>  > > zorro:tmp $  gcjh -classpath ./ricochet.jar multishot.examples.RicochetApp
>  > > zorro:tmp $  gcj -shared -fPIC -Wl,-Bsymbolic ./ricochet.jar -o libricochet.so
>  > > zorro:tmp $ gcj RicochetAppMain.cpp -L. -lricochet -fPIC  -lstdc++
>  > > cc1plus: warning: command line option "-fbootclasspath=./:/usr/share/java/libgcj-4.1.2.jar" is valid for Java but not for C++
>  > 
>  > Ah! This is the missing piece for me. I was linking with g++. I was
>  > assuming since I had a .so library and .h headers I could treat the
>  > transformed .jar file like a C++ library. It never crossed my mind to
>  > compile the C++ file with gcj and link everything with gcj.
>  > 
>  > I assume I will need to use gcj rather than g++ for all my C++ files. Is
>  > this correct?
> 
> I don't think it matters.  I could have done this instead:
> 
> zorro:tmp $ g++ RicochetAppMain.cpp -L. -lricochet -fPIC  -lgcj
> zorro:tmp $  LD_LIBRARY_PATH=. ./a.out 
> 
>  > > Usage: RicochetApp GMS_id FDS_id startPortNumber [propertyString]
>  > > 
>  > > You really need to call JvCreateJavaVM() first.
>  > 
>  > In some other code I have I call JNI_CreateJavaVM. Is this
>  > different from JvCreateJavaVM and, if so, do you know how it
>  > differs? The prototype for JvCreateJavaVM doesn't exist in the
>  > jni.h file that I'm using.
> 
> No, but it is included.  You must call JvCreateJavaVM() as the very
> first call into libgcj.  This is *really* important.
> 
>  > Adding this call raises some questions for me. Does this call add
>  > overhead (and/or footprint)? I was (seemingly naively) assuming
>  > that once the .jar file was converted to a .so file I was done with
>  > needing any Java support. This doesn't seem to be the case. Why is
>  > the JVM still needed?
> 
> There's a ton of stuff: threads, garbage collection, and of course the
> entire Java runtime library.
> 
>  > Are there any other calls I should add?
> 
> I can't think of any.
> 
> Andrew.
>