[kaffe] Re: [Java-gnome-developer] Java-Gnome: jni or cni

Tom Tromey tromey at redhat.com
Thu Mar 11 18:21:02 PST 2004

>>>>> "Elias" == Elias Martenson <elias-m at algonet.se> writes:

Elias> Going CNI-only would severely limit the number of 3'rd
Elias> party component you'd be able to integrate.

You can mix and match CNI and JNI in a single process.  This happens
any time you use JNI in libgcj.  Maybe you meant to say that going CNI
only would mean that you couldn't use java-gnome on non-libgcj
runtimes, which is true.

Elias> The fact that Java is heavily dynamic (sandboxed execution, etc...) is
Elias> an enormous advantage, and I fail to see how an experienced Java
Elias> developer who uses these things could ever even consider turning the
Elias> back on everything that is Java, just to gain a little perceived
Elias> performance.

This is a common misconception of what gcj is all about.

It's true that the AOT compiler is the centerpiece of the gcj
approach.  And it is also true that historically this meant less than
perfect compatibility with the Java specification.

However, it has always been our plan to provide a complete, compatible
Java system.  This year we are making great strides in this area.  In
particular the new binary compatibility ABI will let us erase the few
remaining semantic differences; in essence gcj will look like a sort
of caching JIT more than a pure AOT compiler.

Second, for me at least, the primary consideration isn't the features,
the performance, or any facet of the implementation (including even
AOT compilation if it comes to that).  The primary thing is freedom.
Based on what you say, it sounds like we have different priorities


More information about the kaffe mailing list