Java™ Application Development on Linux - Dator

186Chapter 7The GNU Compiler for Java (gcj)7.6REASONS TO USE GCJYou might think that speed would be the primary reason to use gcj, but this isnot 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 replacementfor javac), but there is a lot more to Java performance than that. First off, bothSun’s and IBM’s JVMs have JIT (“Just-In-Time”) compilers in them, whichconvert 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, initialruns under a JVM are slower than gcj but later loops or iterations are comparableor faster. Also performance of both gcj and JVM code is highly affected bymemory, stack, and garbage-collection parameters which may be modified withcommand-line options or properties files. So speed is not the determining factor.We have not done sufficient testing or measurement to tell you which environmentproduces “the fastest code” from a given source file. (We’re not evensure exactly what such “sufficient testing” might consist of. All we can suggestis that your try your code in all three environments and then make yourown choice.)It is, perhaps, ironic that one of the main reasons why you might wish touse gcj is portability. You see, you can only run Sun’s and IBM’s JVMs onplatforms for which they provide a compiled version. Linux runs on severalhardware platforms (such as StrongARM) for which Sun and/or IBM do notprovide JVMs. Also, if you are running Linux on some architectures, there maybe VMs for the “official” OS, but none for Linux on that architecture. This isthe case, for example, for SPARC and Alpha. The cross-compilation that gcjinherits from the GNU Compiler Collection allows you to compile Java tonative code for Linux on those platforms.Another reason to use gcj might be a desire for better integration withcode compiled from other languages. gcj has JNI support, but also provides itsown inter-language integration system called CNI, for Compiled Native Interface.We don’t have space to cover CNI (and, frankly, we haven’t used itenough to be good judges), but its proponents claim that it is both easier to useand more efficient than JNI. You can read up, use it, and judge that foryourself.Still another reason might be one that we don’t like very much. Again, itis ironic that the only Free Software Java compiler is the one best able to produceproprietary binary code. Code compiled with gcj is as difficult to reverseengineer as compiled C or C++ code. It is subject to the same sort of binary