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
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
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
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
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
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.
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
on Marco Schmidt's web-site, along with another view of the pros and
Back to the main page.