This section provides the following additional information on using jexegen:
Support for onCOMRegister Method
Generating Version 2 Format Resources
How Jexegen Handles Resource Files
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. You must therefore 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, that 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, because the names of the class files in the executable will not reflect their actual names. The correct way to build the .exe file is to run the command jexegen /main:Sample.Main Sample/*.class from the C:\Classes directory. To verify that the correct names are included, use the command jexegen /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.
Jexegen works by binding the class files to a small stub program. This stub simply instantiates the Microsoft virtual machine (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 jexegen /bindto option to add the class resource data to your own stub program. Alternatively, you can use the jexegen /raw option and reference the resulting data file from your program's resource script.
The Samples folder of the SDK for Java includes the source code for a sample jexegen stub.
You can now use jexegen to create COM DLLs with embedded type libraries. The DLL can contain any number of Java/COM objects. COM registration information (CRI) must be provided for Java classes, which tells jexegen how to expose the classes as COM objects. There are three ways to provide CRI for a class:
JAVACLASS("<classname>") specifies the name of the Java class.
PROGID("<text>") specifies the program identifier.
You can use multiples CRI sources. Information from multiple sources will be merged and verified against each other to detect conflicts.
A CRI file is a text file that provides COM registration information for Java classes. You can use CRI files to provide information that cannot be specified in any other way (such as the desired threading model). Each line of a CRI file provides COM information for one Java class.
Use the keywords shown in the following table to provide COM information in a CRI file.
class:<class name> | Required; the name of the Java class. |
clsid:{<GUID>} | The class identifier. If the CLSID is not specified in the CRI file or in any other CRI source (@com.register or MTS typelib attributes), then one is generated via CoCreateGuid. |
progid:<text> | The program identifier. Note that quotation marks are not used. |
TypelibGUID:{<GUID>} | The type library's GUID. |
version:"<decimal>.<decimal>" | The type library's version number. |
description:"<text>" | Description text inserted into the registry as the default value for the CLSID. |
ThreadingModel:<Apartment | Free | Both> | The object's threading model. |
control | Registers the object as an ActiveX control. |
The ThreadingModel:<Apartment | Free | Both> supports the COM+ neutral apartment: it allows you to specify ThreadingModel=Neutral in CRI files. If ThreadingModel=Neutral is specified for a COM object, the COM object’s InprocServer32\ThreadingModel value will be set to Neutral when the DLL is registered.
Only the class:<class name> is required; all other keywords are optional. The keywords can be specified in any order but must be specified on one line in the CRI file. For example:
clsid:{0B765470-A05D-11d2-970C-0080C7E171C0} class:depth.CRIReg progid:BLARG! Typelibguid:{CD94BA10-C560-11d2-9772-0000F8771C2E} control description:"my class" version:"345.1234" ThreadingModel:Apartment
Jexegen now supports the implementation of the static method onCOMRegister. You can use this method to perform additional registration, such as creating custom registry keys needed by a DLL. When you add this method to a COM class, it will be automatically invoked when the COM DLL is registered.
The onCOMRegister method is a user-defined method whose signature must match the following signature:
public static void onCOMRegister(boolean isRegister) { // Add your custom registration code here }
Jexegen now generates version 2 format resources which can contain arbitrary data files. This allows you to include files in the executable that could previously only be placed in the class path, in a .zip file, or by using some other method. To add arbitrary files, use the same jexegen syntax as for class files. For example:
jexegen /main:Hello /out:Hello.exe Hello.class Hello.dat
If jexegen encounters a file that is not a class file (in this example, Hello.dat), it automatically generates a version 2 format resource. You can use the /maxver option to force jexegen to generate a version 1 format resource (which can only contain class files).
Previously, jexegen classified all files that were not class files as Java resources. Now, jexegen applies the following rules before determining that a file should become a Java resource:
Note the following limitations when using jexegen:
This section contains examples of how to use jexegen.
On the jexegen command line, you must specify the class files you want to include and the name of the class file containing the main method.
For example, assume you have a Java application that consists of three class files: A.class, B.class, and C.class. A.Class contains the application's main method. To generate an executable, 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 following command line creates the executable file, Hello.exe, from a single .class file, Hello.class:
jexegen /main:Hello /out:hello.exe Hello.class
The following command line creates the executable file, classvue.exe, from all classes in the ClassVue directory in the Microsoft SDK for Java:
jexegen /main:ClassVue /out:classvue.exe *.class