Creating an EXE file

1. AOT compilation

   Use an AOT (Ahead Of Time) 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. Examples are JET and gcj. This the only technique that speeds up execution. The following techniques are kludges to make Java look like a familiar exe file, without truly being one.

2. Shortcuts

   Set up a shortcut with the appropriate java.exe command to load the class.

3. Executable Jars

   Bundle your classes in a jar with the Main-Class attribute. Set up an association for *.jar to make it executable.

4. Independent Kickers

   Write yourself a tiny C kicker program that exec’s a Java command to load your class. Assuming the jar file Foo.jar with main class Bar, here how to make 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;
   }

5. Self Contained Kickers

   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. In this case your custom foo.c kicker code will look like this:
   #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.

6. Installer

   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.

7. Class Wrapper

   The Microsoft SDK for Java included a tool called jexegen which turned your *.class file(s) into an *.exe file. It didn’t compile them or convert them to machine code; it just stuffed 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 needed access to the Microsoft JVM to work, unlike true native *.exe files which are standalone and written in machine code.

   Though Microsoft’s Jexegen and Webgain Café and Sun’s J2Exe are gone, there are other programs that use the similar wrapping technique:

   • Java2exe
   • JEXECreator
   • exe4J
   • JavaLauncher

8. Java Web Start

   Distribute using Java Web Start. Users can click on menu or desktop items to kick off pure java Programs.

Advantages of Native Compilation

1. 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 Hotspot.

2. Load speed

   A natively compiled program will load and start execution much faster than one using Java 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. Java 1.5+ load time are vastly improved and so the need to convert jars to native code is much less pressing than in past.

3. Self-Contained Distribution Package

   Java, or even Java Web Start requires the customer to pre-install the JRE. You may not be legally permitted to bundle that JRE with your app. You are most certainly not permitted to strip out the parts your app does not need. The customer has to go get and install the JRE 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.

4. 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 than distributing tradiditional class files plus a JRE.

5. Security

   Native apps, especially optimised apps, are much harder to decompile (reverse engineer).

6. 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.

7. 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.

Disadvantages of Native Compilation

1. 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.

2. Cost

   The compiler is an extra cost item.

3. 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.)

4. 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.

5. 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.

6. Applets

   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.

7. Java Web Start

   You can use native compilers with Java Web Start Weblets, but only after unpacking jars, bypassing security restrictions and execing the native exe.

Bottom Line

So left standing are:  Excelsior JET, and gcj.