java gnu_GNU Compiler for Java

GCJ can compile Java source code to either Java Virtual Machine bytecode, or directly to machine code for any of a number of CPU architectures. It can also compile class files containing bytecode or entire JARs containing such files into machine code.

History

Almost all of the runtime-libraries used by gcj come from the GNU Classpath project (but compare the libgcj library). As of gcj 4.3, gcj integrates with ecj, the Eclipse Compiler for Java.

As of 2007 a lot of work has gone in to getting GNU Classpath to support Java's two graphical APIs: AWT and Swing. Work on supporting AWT is ongoing, after which support for Swing will follow.

As of 2009 there have been no new developments announced from gcj.

Performance

Java code compiled into machine code by GCJ should have faster start-up time than the equivalent bytecode launched in a JVM.

However, after start-up, Java code compiled by GCJ does not necessarily execute any faster than bytecode executed by a modern JIT-enabled JVM. This is true even when GCJ is invoked with advanced optimization options such as -fno-bounds-check -O3 -mfpmath=sse -msse2 -ffast-math -march=native; in this case, the compiled program may or may not surpass JVM performance, depending on the operations performed by the code in question.

CNI (Compiled Native Interface)

The CNI (Compiled Native Interface, previously Cygnus Native Interface), a software framework for the gcj, allows Java code to call and be called by native applications (programs specific to a hardware and operating-system platform) and libraries written in C++.

CNI closely resembles the Java Native Interface (JNI) framework which comes as standard with various Java virtual machines. However the CNI authors claim various advantages over JNI:

“

We use CNI because we think it is a better solution, especially for a Java implementation that is based on the idea that Java is just another programming language that can be implemented using standard compilation techniques. Given that, and the idea that languages implemented using Gcc should be compatible where it makes sense, it follows that the Java calling convention should be as similar as practical to that used for other languages, especially C++, since we can think of Java as a subset of C++. CNI is just a set of helper functions and conventions built on the idea that C++ and Java have the *same* calling convention and object layout; they are binary compatible. (This is a simplification, but close enough.)

”

CNI depends on Java classes appearing as C++ classes. For example,

public class Int

{

public int i;

public Int(int i) { this.i = i; }

public static Int zero = new Int(0);

}

one can use the class thus:

#include

#include

Int *mult(Int *p, int k)

{

if (k == 0)

return Int::zero; // Static member access.

return new Int(p->i * k);

}