Etienne Gagnon wrote:
GCJ is mainly a GCC extension, targeting static compilation of Java to native code and/or bytecode.
GCJ aims to be a complete full-featured Free Java implementation.
It includes a minimal, but incomplete interpreter (gij).
Gij may have bugs, and we certainly make no claim that the bytecode verifier or security is robust enough to make it suitable for running possibly hostile code. However, as far as I know it is "complete".
We would be happy to integrate a JIT into GIJ, as an option.
> Its main native interface is CNI (Cygnus Native Interface)
I think officially it's now the "Compiled Native Interface".
which is convenient for linking with C++ code,
And an order of magnitude faster.
but which is non standard (incompatible with JNI)
which is why GCJ also implements JNI
and is also incompatible with precise and moving garbage collectors.
I don't believe it is incompatible with a precise collector. (Emacs uses a precise collector.) Nor is it *inherently* incompatible with a copying collector - you just have to teach the C++ compiler to emit the necessary tables so the collector can update all the pointers. That is a very hard problem. Furthermore, it has been claimed that JNI also in practice requires a conservative collector. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
