Java Runtime

The following parameters apply to the Java runtime used by the executable:

• Baseline version. This indicates the baseline JRE version required by the application. For example, if the JRE installed on the target machine is 1.2, but the minimum version required is 1.3, then the executable will display an error message and exit. This argument only applies if JVM DLL is left blank i.e. if you did not bundle a specific JRE with your application.
• JVM DLL. When this parameter is left blank, the executable will automatically look for a suitable JRE on the target system. However if you are bundling a specific JRE with your application, you can specify the relative path to the JVM DLL eg. jre\bin\hotspot\jvm.dll. Multiple JVM DLLs can be specified by delimiting the pathnames with semi-colons.
• JVM search order. By default, the executable will use the private JRE if one is available. Otherwise, it will search for a suitable Java Runtime Environment (JRE) on the target machine. If that fails, then it will search for a suitable Java Developer Kit (JDK). You can change the order of search, as well as restricting the search to only the JRE or JDK.
  
  Please refer to How NativeJ searches for a suitable JDK/JRE for more information on this topic.
• JVM options. The options to pass to the JVM. You should only pass the ‑X or ‑D options to the JVM eg. ‑Xms64m ‑Xmx128m. Note that some ‑X options are JVM version-dependent. For more information, refer to Passing options to the Java runtime.
• Classpath. Specify the classpath required by the application. Multiple entries are delimited by semi-colon. Each entry in the classpath could be a JAR or ZIP file. If the entry is a directory, all the JAR and ZIP files in that directory will be dynamically appended to the final classpath at runtime. This operation is recursive, hence all subdirectories will also be searched for JAR or ZIP files.
  
  If you are bundling a specific JRE with your application, there is another way to specify the class files required by your application. For more information, refer to An alternative approach to classpath.
  
  This field is required.
• Embedded JAR files Specify the JAR or ZIP files you wish to embed into the final executable. When the executable is run for the first time, these JAR files will be extracted into a temporary directory and appended to the classpath. Subsequently, as long as the JAR files are not modified or removed, the extraction step will be skipped. Note that this could increase the size of the final executable tremendously, depending on the total size of the embedded JAR files.
  
  Please refer to JAR files embedding for more information on this topic.
• Extract to Specify where to extract the embedded JAR files to. By default, they are extracted to the system temp folder. You can change this parameter to extract the embedded JAR files to the application folder (which is the same folder where the EXE file resides), or to the application temp folder (which is a temporary subfolder within the application folder).
• Delete JAR files when EXE terminates Normally, embedded JAR files are not deleted once they are extracted into a temporary directory. This enhances startup speed because the extraction step will be skipped when the application is run the next time. However, if you want the embedded JAR files to be removed when the executable terminates, select this checkbox.

Environment variable substitution

Before the JVM options and classpath values are passed to the runtime, a final substitution is made where all tokens of the form %name% are replaced with the value of the equivalent environment variable. For example, if the classpath contains myapp.jar;%CLASSPATH%, and the CLASSPATH environment variable on the target machine contains mydriver1.jar;mydriver2.jar, then the final classpath will contain myapp.jar;mydriver1.jar;mydriver2.jar after substitution.

A special case is %JAVA_HOME% (case-sensitive), which will always be substituted for the actual base directory of the JDK/JRE that is found on the target machine. For example, if the classpath contains %JAVA_HOME%\lib\tools.jar, and a suitable JDK is found in C:\j2sdk1.4.1_02, then the final classpath will contain C:\j2sdk1.4.1_02\lib\tools.jar after substitution.