Most compilers generate JVM byte codes. Native Code Compilers will
optionally generate native *.exe files. JITs create native code at execute time,
but don't create *.exe files. The Microsoft SDK for Java includes a tool called jexegen
which turns your .class file(s) into an .exe file. It doesn't compile them or
convert them to machine code; it just stuffs the contents of the .class files
into the .exe file along with some code to pass those bytecodes to the MS JVM to
be interpreted. The resulting exe files need access to the Microsoft JVM to work,
unlike true native exe files which are standalone and written in machine code. download
it as part of the Microsoft SDK for Java 4. There is a similar product called Java2exe.
Here are eight ways to get what acts like a Java executable file:
-
Use a native compiler. This is the only method that gives you a true machine
code executable. You may still have to distribute some DLLs or the JRE along
with your executable.
-
Set up a shortcut with the appropriate java.exe
command to load the class.
-
Bundle your classes in a jar with the Main-Class
attribute. Set up an association for *.jar
to make it executable.
-
Write yourself a tiny C program that exec's a Java command to load your class.
Assuming the jar file Foo.jar with main class Bar,
here how to making a Foo.exe tiny kickoff program.
Compile the following program foo.c to foo.exe:
#include <process.h>
int main(void)
{
execlp("java.exe",
"java.exe",
"-cp",
"foo.jar",
"Bar",
NULL);
return 0;
}
If you want to play really strange games, concatenate the jar file onto the end
of your foo.exe kicker, and put the EXE file on the
classpath where you would normally need to place foo.jar.
This way you can distribute but a single file, albeit uncompressed. Reputedly java.exe
will happily treat this combo as a standard jar. Executing the foo.exe
just ignores the jar tacked on the end. e.g. change the foo.c code to read
#include <process.h>
int main(void)
{
execlp("java.exe",
"java.exe",
"-cp",
"foo.exe",
"Bar",
NULL);
return 0;
}
then
rename foo.exe littlefoo.exe
copy /b littlefoo.exe + foo.jar foo.exe
You only need distribute foo.exe.
-
Use the InstallAnywhere NOW installer (or other installer).
It uses a standard platform-dependent EXE
kickoff file for a standard interpreted platform-independent Java application
packaged in a jar file.
-
Use Microsoft's Jexegen bundler. It only works with
the Microsoft JVM. Webgain Café also works
this way as does J2Exe.
-
Distribute using Java Web Start. Users can click on menu or desktop items to
kick off pure java Programs.
-
Use exe4J
bundle up your jar file and a copy of the JRE into one big installable exe file.
Your program runs in the standard Sun Hotspot JIT.
What are the advantages of a native compiler?
-
Execution speed
Visit any of the vendor sites, such as Jet for independent
benchmarks. The improvement is even more marked for old clunker machines
that your customers may use. Native compilations tend to me more scalable, doing
well as you add more threads. Depending on just what you are doing, you may get
over twice the speed of Java 1.4.1 Hotspot.
-
Load speed
A natively compiled program will load and start execution much faster than one
using Java 1.4.1 JVM. Customers resent slow load times even more than slow
execution times. They have nothing to do but sit there and wait. JITed Java is
precluded from many applications because of its extraordinarily slow load time.
Natively compiled Java opens the doors to all the traditional C applications.
-
Self-Contained Distribution Package
Java, or even Java Web Start requires the customer to pre-install the JRE. You
are legally not permitted to bundle that JRE with your app. The customer has to
go get it for himself. Native apps can be distributed in familiar ways as
totally self-contained packages. On the other hand, once Java Web Start is
installed, the end user can install new apps with a single click.
-
Distribution size
Java class files are quite tiny, but they need the entire JRE to make them work.
If the customer has Java already installed, then the class files packed in a jar
are exceedingly compact. However, if he does not have Java installed, that then
the native distribution will be smaller.
-
Security
Native apps, especially optimised apps, are much harder to decompile (reverse
engineer).
-
Prejudice
The customer need not know your app is written in Java. Some customers are
Microsoft fanatics who follow the party line that Java is slow or evil.
-
Code Sharing
Compilers like Jet, bundle classes into DLLs. This means
if you have two JVMs running, you need only one copy of the DLL in RAM. This
makes more efficient use of RAM.
What are the disadvantages of a native compiler:
-
Single Platform
Your code works on only one platform. Even if you buy a multiplatform compiler,
you need to generate different versions, one for each platform, and different
install scripts for each platform. It is even more import than ever to test the
code on each platform.
-
Cost
The compiler is an extra cost item.
-
Complexity
Distribution is more complex with DLLs and EXEs and an install script. (Jet
comes with an install generator, so you don't necessarily have to buy
Installshield or equivalent.)
-
DLL version hell
In place of the problem of mixed generations of JRE, you have the problem of
mixed generations of support DLLs on your client site.
-
Learning Curve
Native compilation is more complex than standard compilation. You need to learn
new skills to master it, e.g. dealing with a mixture of static and dynamic class
loading. It is quite simple. The only mildly complicated thing is dealing with
dynamic class loading.
-
You can't use native compilers on Applets. In theory
you could compile your app as a DLL and make pure java hooks in to it. You would
have to design your app as a dll, sign it, arrange for installation of the DLL.
The game is hardly worth the candle.
-
You can use native compilers with Java Web Start
Weblets, but only after unpacking jars, bypassing security restrictions and
execing the native exe.
Most native code compilers are for Windows, though TowerJ creates native code
for various Unices. Supercede has been sold to the Jove people, leaving the
floor to Jet, BulletTrain, IBM Visual Age and JBuilder,
Excelsior
JET, GNU Java Compiler for Linux;
Jove, Webgain Café, TowerJ and gcj.