gcj suitable for native-wrappers for launching java?

Thu Feb 19 17:23:00 GMT 2004

On 2004年2月19日 Andrew.Ferguson@arm.com wrote:
> i was wondering if gcj is suitable for creating native-wrappers for
> launching a java program via a named jvm (in the same was as projects such
> as JSmooth)? ie. the original java application still runs on a full-blown
> jvm, but the bootstrapping and setting up of environment is done by a
> native stub. Open-source projects for this seem to be very windows
> oriented.

If you mean a wrapper for e.g. Sun's JVM, no. Gcj has no special support
for any VM besides its own bytecode interpreter.
But if it's gcj/libgcj you're after, there are some options. You can
even write a small wrapper in Java, and compile to native:
public class Wrapper {
 public static void main(String[] args) {
 try {
 Class.forName("MyClass");
 } catch (Exception ex) {
 ex.printStackTrace();
 }
 }
}
public class MyClass {
 static {
 System.out.println("MyClass loaded from bytecode by wrapper");
 }
}
$ gcj Wrapper.java --main=Wrapper -o wrapper
$ gcj -C MyClass.java
$ ./wrapper
MyClass loaded from bytecode by wrapper
You can set the java.class.path property to burn a CLASSPATH into wrapper,
and probably there's a way to get a library path in there too.
Or write a C/C++ wrapper with CNI or JNI invocation. though there's
obviously a little more to it.
(I agree that such projects are Windows oriented. Everyone else seems
happy with a shell script.)
> having done some tiny experiments with gcj and got things working on
> windows, i've compiled on solaris but theres another bootstrapping problem
> of setting up the LD_LIBRARY_PATH - something that end-users with a clean
> machine can't be expected to do. i've had a go at static linking libgcc and
> libgcj but not been able to get it to work - is this a sensible thing to be
> trying to do? once i'd got that working i'd need to do the same for linux
> and HP/UX platforms - so i guess my question is whether to give up now :)

Static linking libgcj is problematic, but sometimes works. Can you link
using -rpath instead? Will you know the library path prior to
installation?
If you go the pure JNI/CNI invocation route, you may be able to dlopen()
libgcj.so knowing the path at runtime.
I don't know if HP/UX even has a working gcj, that's another problem :-(
Jeff