Introduction to Jexegen

The jexegen tool is used to create Microsoft® Win32® executables from Java applications. The class files for the application are bound into the executable, and do not need to exist anywhere else on the drive. Note that the Microsoft Win32 VM for Java is required to run programs generated by the jexegen tool.

Basic Operation

You must specify on the jexegen command line what class files you want to include and the name of the main class file. For example, you have a Java application that consists of three class files—A.class, B.class, and C.class—and that class A contains the application's entry point (the main method). To generate an executable, you would run the following command from the directory that contains the class files.

jexegen /main:A /out:MyApp.exe A.class B.class C.class

In this case, the jexegen tool creates the file MyApp.exe, which contains your Java application.

The jexegen tool uses virtual paths in command line arguments. It is important that the jexegen tool is in your CLASSPATH environment variable, as well as the classes you are working with. If jexegen is not in the CLASSPATH, the utility must be run from the directory where the associated classes are located (in particular, any classes that contain main()), or an application error occurs. For example, the following command will not work.

C:\>\SDK-java\bin\jexegen /v c:\_java\BsetEditor\*.class 
   c:\_java\BsetEditor\sun\audio\*.class ...

The jexegen utility is running directly from bin, and absolute paths are used. This results in an "Ignoring file.." message. You can avoid this by adding jexegen to your CLASSPATH and by using virtual paths in command line arguments. Also note that the classes you include on the command line need only be a package name (for more information, see Working with Package Names), as the following example shows.

C:\_java\BsetEditor\>jexegen /V com.ms.ui.*.class ...

Reference to Jexegen Command-Line Options

jexegen [options] [@command file] files  

The options are as follows:

/main:classname	(Required) Sets the name of the main class file. This class must contain the public static method main. The name specified on the command line must be the same as the class's internal name; it is case-sensitive and you must separate package names with periods. For example, if you usually run your application with the command line: view MySample.Sample then the appropriate switch for jexegen would be: /main:MySample.Sample
/nomain	Indicates that you do not want to specify a main class file. This option is useful only in conjunction with the /raw or /bindto option.
/base:dir	Changes the base directory; used to determine package names of specified class files. When used with the /raw or /bindto option, this option specifies the base directory that file operations are relative to. By default, package names and file operations are determined relative to the current directory. If used more than once on the command line, all /base options are relative to the original (current) directory.
/out:filename	Specifies the name of the output file.
/r	Indicates that jexegen should recurse into subdirectories when searching for the specified class files. By default, subdirectories will not be searched.
/r-	Used to turn off subdirectory recursion. Only useful if the /R option has already been used. As an example, consider the following partial command line: /r This*.class /r- That*.class This example command line instructs jexegen to find all class files matching This*.class in the current directory and all subdirectories, and all files matching That*.class only in the current directory.
/v	Provides detailed output.
/w	The generated executable will not have an associated console window. This option will be useful only for graphical applications.
/bindto:stub	Specifies the executable (.exe file) or dynamic-link library (DLL) to bind the class resources to.
/raw	Saves resource data to a file and does not generate an executable. The data file generated is of the appropriate format to be used with the IJavaExecute2::SetClassSource method.

Working with Package Names

Be sure to preserve package names when using the jexegen tool. The package names of the classes to be bound into the executable are determined by the directories in which those class files are located. Therefore, you must run the jexegen tool from a directory above the directory containing the class files.

For example, a Java application consists of two class files, Main.class and Helper.class, which exist in a package called Sample. The files are in the c:\classes\Sample directory.

  c:\classes\Sample\Main.class
  c:\classes\Sample\Helper.class

If the command jexegen /main:Main *.class is run from the c:\classes\sample directory, the generated executable will not work correctly: The names of the class files contained within the executable will not reflect their real names. The correct way to build the .exe file is to run jexegen /main:Sample.Main Sample/*.class from the c:\classes directory. To verify that the correct names are included, you can use the /v option to observe the names of class files that are stored in the executable.

By default, the current directory is used as the base directory. Package names are determined relative to the base directory. You can use the /base option to specify an alternative base directory.

Command Files

As an alternative to specifying all the class files and options on the jexegen command line, you can use a command file. A command file contains a list of options and file specifications, one per line. For example, this command line:

C:\..\>jexegen /main:myapp /out:myapp.exe 
             Myapp.class Fido.class Fido2.class Fido3.class 

can be replaced with the following command line:

 jexegen @myapp.dat 

where the contents of the file myapp.dat is:

  /main:myapp
  /out:myapp.exe
  Myapp.class
  Fido.class
  Fido2.class
  Fido3.class

Custom Stubs

The jexegen tool works by binding the class files to a small stub program. This stub simply instantiates the Microsoft VM, and uses the IJavaExecute2::SetClassSource method to tell the VM that it should look for class files inside the executable.

If the built-in stub is insufficient for your needs, you can provide your own stub file. For example, a custom stub could contain version information or a custom icon. You can use the /bindto option of the jexegen tool to add the class resource data to your own stub program. Alternatively, you can use the /raw option and reference the resulting data file from your program's resource script.

The SDK for Java includes the source code for a sample jexegen stub.