Bundling a private Java runtime

When you leave the JVM DLL parameter blank, the generated executable will detect and use the the first JRE installed on the target machine which meets the JVM version requirement.

It is also possible for you to bundle a private JRE with your application, and generate an executable that uses the bundled JRE regardless of other runtimes installed on the target machine.

There are a few advantages to bundling a private JRE with your application.

The primary concern with bundling your own JRE is the footprint of your application. Bundling your own JRE potentially increases your distribution and installation footprint by tens of megabytes. If the application needs to be delivered via the Internet, or the target system has diskspace constraints, then bundling your own JRE may not be acceptable.

The decision of whether to bundle or not to bundle your own JRE depends on the factors mentioned above. However, if you do choose to bundle your own JRE, it is very simple to do so with NativeJ.

Let's say we decide to bundle a private JRE for our first example program, examples.Console. Originally, the application directory contains only the executable console.exe and examples.jar.

approot\
  console.exe
  examples.jar

Let's copy an existing JRE installed on your machine to your application directory. The application directory should now look like:

approot\
  jre\
    bin\
      client\
        jvm.dll
      ..
      (other files such as java.dll and awt.dll etc.)
    lib\
      ..
      (other files such as charsets.jar and rt.jar etc.)
  console.exe
  examples.jar

The jvm.dll under jre\bin\client\ (in some JREs, they are located under jre\bin\classic\, jre\bin\hotspot\ or jre\bin\server\) represents the different JVMs which you can use. The classic JVM refers to the non-JIT, interpreted JVM. The hotspot JVM uses Sun's HotSpot JIT technology, and is optimized for client applications. The server JVM is also a HotSpot-JIT JVM, but is optimized for server applications.

Note that the structure above varies according to the make and version of the JRE. For example, in Sun's JDK 1.2, the classic JVM refers to a JIT JVM licensed from Symantec. The Hotspot JVMs were only introduced in JDK 1.3. Similarly, the structure for IBM's JDK, or JDK from other vendors could be different.

Once you have copied the jre\ subdirectory to your application directory, you can generate an executable that will make use of that private JRE. Just specify the relative path to the desired JVM DLL file in NativeJ, and generate the executable. For example, if you specify jre\bin\hotspot\jvm.dll in the JVM DLL parameter box, it means you want to use the client-optimized HotSpot JVM for your application.

Finally, create an installer that will replicate the entire application directory to the user's machine. This is easily done with a modern installer maker by using the project wizard and specifying the root directory of the application to be bundled.