Java native compilers

Note: There is also a page for Java bytecode compilers.

Introduction to the concept of native compilation

Diese Einführung ist auch auf deutsch verfügbar, als Teil der FAQ der Newsgroup de.comp.lang.java (alternativ: http://www.faqs.org/faqs/de/comp-lang-java/faq/).

Different from normal Java bytecode compilers (like javac or jikes), native compilers do not create bytecode files (.class) that are interpreted by a Java Virtual Machine but native executables (like .exe files on Windows). "How do I create an EXE from Java?" is a very frequently asked question in newsgroups like comp.lang.java.programmer, native compilers are the answer. Some native compilers are listed below, check them out. However, consider the following pro/contra comparison when you decide whether or not to use a native compiler.

If you are just looking for ways to make it easy for your users to get your Java application running, consider Java Web Start, InstallAnywhere, NativeJ or JExpress. Executable JAR files are also a good alternative - give your users the application in a single file. They can even start it by simply double-clicking it on some platforms (like Win32).

Pro native compilation

Higher execution speed. Actually, that is not guaranteed, it depends largely on the application type, the system environment, the way a particular solution was coded etc. You must do a lot of testing to find out if your code benefits from native execution.
Faster startup time. Native applications typically start faster than bytecode applications. That doesn't matter if your program runs for a very long time, but for small command line applications that get started often it might make a difference.
Easier deployment. It seems to be better to give Windows users an EXE file - they know what it is, how to run it, etc. However, JAR files with a main-class manifest entry can also be run by double-clicking on them (with certain JREs). Installation wizards are also available. Often, developers don't want their users to have to install a JRE. But with many native compilers, you have to have a JRE and various other code installed to run the EXE, so there is no real simplification.
Higher number of concurrent program instances. Every instance of a JVM requires at least several MB of RAM, while some of the more advanced native compilers create executables that share memory between instances of the same application. That way, you can run more instances on the same system.
Better code obfuscation. If you don't want people to reverse-engineer your code, native executables are typically harder to understand than bytecode, even if the bytecode was run through an obfuscator.

Contra native compilation

No more platform independence. Instead of having a single JAR for your application that runs with every JVM, you have to maintain several versions. This is very much against the Write Once, Run Anywhere idea that was one of the reasons to create Java in the first place.
Less platforms. From what I can see, there are no native compilers for several platforms, so that the number of potential users is smaller with a native application. However, the most important platforms seem to be supported, so that the absolute number of potential users is not much smaller.
Higher costs. It seems that all good native compilers are relatively expensive. This does not apply in a commercial environment where spending several thousand US dollars on a product is not unusual.

Native compilers - Products

If you know of native compilers not listed here, send me a mail. Please read these remarks first.

BulletTrain

http://www.naturalbridge.com/

~~Commercial bytecode-to-native compiler for Win32, tuned for high execution and startup speed, compatible with Java 2.~~ The company NaturalBridge Inc. still exists, but they do not seem to sell the native compiler BulletTrain anymore.

CRTJVAPGM

http://www-1.ibm.com/servers/eserver/iseries/toolbox/perfhints.htm

A tool for iSeries and AS/400 systems that convert class files to native code. Also see this manual.

Note that the above link does not point to a product page, I just didn't find anything better. -- Marco

Excelsior JET

http://www.excelsior-usa.com/jet.html

JET converts Java 2 bytecode to native Win32 or Linux x86 code. There are various versions for commercial, academic and private use.

More information on requirements and dependencies for the created native executables can be found in the JET FAQ.

gcj

This is both a source-code-to-bytecode compiler and a native compiler. See the gcj description on the bytecode compiler page for details.

javaCompiler

http://javaCompiler.sourceforge.net

Compiler to create native executables for Windows, Linux and MacOS. Supports Java 1.5 and the GUI toolkits AWT, Swing and JFace. Relies on gcj. Distributed under the GPL.

JOVE

http://www.instantiations.com/jove/

~~Commercial bytecode-to-native compiler for Win32, optimized for high execution speed. Compatible with JDKs up to 1.3, including AWT and Swing support.~~

It seems that the product is discontinued. From the website:

Instantiations is no longer marketing or selling the JOVE product.

Manta

http://www.cs.vu.nl/~robn/manta/

A Java 1.1 native compiler for Linux x86. Released under the GPL.

Swift

http://h18012.www1.hp.com/java/download/unix/1.3.1/index.html

An Ahead-of-time (AOT) compiler for the Fast Virtual Machine. Available for Tru64 Unix.

TowerJ

http://www.towerj.com/

TowerJ takes Java bytecode and turns it into native binary executables for maximum speed of server-side Java applications. This is a commercial product with support for the Solaris Operating Environment, HP/UX, Windows, Linux, Tru64, DG/UX, AIX and SGI. It is compatible with Java 2.

It seems that Tower Technology has ceased to exist.

VisualAge for Java

~~http://www-4.ibm.com/software/ad/vajava/library/vaj2os390.html~~

The above link does not work anymore and I was unable to find a replacement.

VisualAge for Java, Enterprise Edition for OS/390 contains a compiler to convert bytecode to native machine code.