Converting a Java application into an exe file

This question is sometimes asked many times on a single day in the comp.lang.java.* newsgroups, and I always end up asking the same question: why do you want to? Most answers fall into one of four categories, and each prompts a different course of action. Most of the time, an exe file isn't actually required.

Reason 1: Speed

"Java is interpreted, so I want to make it native and make it faster." Well, very few modern desktop VMs actually spend much time interpreting Java bytecodes these days. Everyone and their dog has a JIT (Just In Time) compiler which will compile your code into native form before running it. Smart VMs will do this only when appropriate (ie if the code is going to be run more than once, or contains loops etc), and may recompile the code on the fly if the conditions change (eg if a subclass is loaded which invalidates some inlining optimisations, or if the code is run very frequently and therefore merits more aggressive optimisations). The bottom line is that for most applications, Java running on a VM is pretty fast these days. It's usually pretty close to the speed of a natively compiled and similar C/C++ application - certainly I've seen changing compiler (or compiler options) for C/C++ make more difference to speed than going between Java running on a VM and natively compiled Java.

There are some situations where the speed difference is significant. If you're really desperate for that extra bit of performance, try evaluating one of the native compilers listed here with your particular application. Make sure you write some real benchmarks though - vague notions of "feeling faster" may well be down to preconceptions.

Remember, too, that as new VMs come out, they tend to improve performance. That means that to get the best out of your application if it's running on a VM, the user only needs to download a later VM - no action is needed on your part. If they're using your natively compiled code, you'll probably need to recompile on a later version of the native compiler, if one is available.

Reason 2: Being able to open an application by double-clicking on it

If you can ask the user to install a JRE first, executable jar files are the way to go here. They're very simple to set up and use, and it won't cost you any money. See "Jar" in the Java Glossary for further information on how to create an executable jar file.

Reason 3: Not having to distribute a jar file and the JRE

Well, in some form or other, your users will need a runtime environment. Some native code compilers even require you to have a JRE installed as well! Chances are you're not going to be able to create a much smaller download, if that's the worry. However, there are other options here which make it easy to install your application. There's Java Web Start which also includes automatic upgrading of your software, but which will impose some restrictions (a bit like an applet, but slightly less restrictive) unless you sign your application. Alternatively, there are quite a few installers available, some of which are free (or free for personal use). See Installer in the Java Glossary for a list of some of them.

Reason 4: Intellectual property protection

Java byte-code can be decompiled pretty easily, and even obfuscators can only do so much. Here, native compilers really do make a difference. Obviously they won't make your code totally impossible to understand, but it'll be very difficult to get back to Java sources which could be modified and recompiled. The only further question to ask at this stage is whether the downsides of native compilation (eg it being a less-well-used (and therefore likely to be less solid) platform, being expensive etc) are worth the upside of the added protection. In some cases the answer will be yes, in some cases the answer will be no.

What next?

If, after reading through the above, you still want to try a native compiler, you can usually evaluate them before buying them. (Some are free, of course.) There's a list on Marco Schmidt's web-site, along with another view of the pros and cons.

Back to the main page.