Java is great for solving many kinds of problems, but it isn’t the first programming language that comes to mind when application performance is a critical issue. Sure, you can try to work around this with more powerful hardware, but at some point, a program written in Java just isn’t going to run any faster.
Java is great for solving many kinds of problems, but it isn’t the first programming language that comes to mind when application performance is a critical issue. Sure, you can try to work around this with more powerful hardware, but at some point, a program written in Java just isn’t going to run any faster.
One way to speed things up is to recode parts of your application into C, C++, or even assembly language and then call these functions via JNI, the Java Native Interface (http://java.sun.com/j2se/1.3/docs/guide/jni). However, this would take costly development time and would jeopardize the portability that is Java’s hallmark.
In a way, the design of Java itself works against you. The Java compiler javac does not generate truly native instructions like gcc and g++ do for C and C++. Instead, the Java compiler generates bytecodes, which must then be converted into native instructions by the Just In Time (JIT) compiler of the Java Virtual Machine (JVM). This step takes time that native executables do not require.
So is there a way to “go native” with Java and to compile your Java source code into a native executable? Yes, there is. gcj, which is a part of the GNU Compiler Collection (GCC), is a direct-to-native compiler for Java that takes Java source code as input and produces machine-native binaries.
gcj comes with a whole bunch of support utilities, most of which are described in Table One; in addition, lots of information on gcj…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
