Section 7.6. Reasons to Use gcj

7.6. Reasons to Use 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 comparable 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 factor. We have not done sufficient testing or measurement to tell you which environment 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 Interface. 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 produce 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 obfuscation as other native compiled code. If you need to make your code closed and proprietary, gcj may be the right tool for you. Naturally, we aren't very fond of this idea, but it is still a reason one might choose the tool.

Finally, we mentioned that speed wasn't a certain factor for choosing gcj, but there is an exception. So far,^[15] Java is particularly slow at starting and shutting down virtual machines. If you have a Java program that is invoked on demand or in a loop and the VM is started and stopped on each invocation, then gcj will give you a huge speed improvement, even if the code executes at the same speed or slightly slower than the JIT JVM code.

^[15] Sun claims that Java 5.0 will show considerable improvement in VM initialization speed.