The GNU Compiler for Java (gcj) - Java Application Development on Linux - page 186

7.6 R EASONS TO U SE GCJ

You might think that speed would be the primary reason to use gcj , but this is
not necessarily the case. Yes, gcj is usually used as a native code compiler
(it can compile to Java bytecode as well, and thus can be used as a replacement
for javac ), but there is a lot more to Java performance than that. First off, both
Sun's and IBM's JVMs have JIT (“Just-In-Time”) compilers in them, which
convert some or all of a class's bytecode to native code on the fly. In some cases,
these compilers may do a better job than the gcj compiler, so as a result, initial
runs under a JVM are slower than gcj but later loops or iterations are compara-
ble or faster. Also performance of both gcj and JVM code is highly affected by
memory, stack, and garbage-collection parameters which may be modified with
command-line options or properties files. So speed is not the determining fac-
tor. We have not done sufficient testing or measurement to tell you which en-
vironment produces “the fastest code” from a given source file. (We're not even
sure exactly what such “sufficient testing” might consist of. All we can suggest
is that your try your code in all three environments and then make your
own choice.)
It is, perhaps, ironic that one of the main reasons why you might wish to
use gcj is portability. You see, you can only run Sun's and IBM's JVMs on
platforms for which they provide a compiled version. Linux runs on several
hardware platforms (such as StrongARM) for which Sun and/or IBM do not
provide JVMs. Also, if you are running Linux on some architectures, there may
be VMs for the “official” OS, but none for Linux on that architecture. This is
the case, for example, for SPARC and Alpha. The cross-compilation that gcj
inherits from the GNU Compiler Collection allows you to compile Java to
native code for Linux on those platforms.
Another reason to use gcj might be a desire for better integration with
code compiled from other languages. gcj has JNI support, but also provides its
own inter-language integration system called CNI , for Compiled Native Inter-
face. We don't have space to cover CNI (and, frankly, we haven't used it
enough to be good judges), but its proponents claim that it is both easier to use
and more efficient than JNI. You can read up, use it, and judge that for
yourself.
Still another reason might be one that we don't like very much. Again, it
is ironic that the only Free Software Java compiler is the one best able to pro-
duce proprietary binary code. Code compiled with gcj is as difficult to reverse
engineer as compiled C or C++ code. It is subject to the same sort of binary