You are here: Duckware » JexePack   Contact us  

JexePack   JexePack 8.4a
JavaTM application to EXE packager
(previously named Java2exe)

  1. What is JexePack?
JexePack Manual Index
1. What is JexePack
2. Using JexePack
3. Command Line Options
4. 'How To' Guide
5. Case Study
6. How JexePack works
7. jWalker debugger
8. Understanding Directories
9. Trouble Shooting Guide
9.1 Capture Program Output
10. Deployment Checklist
11. Technical Notes
12. How to register/order
13. License Agreement
14. Release History
15. How to modify PATH var
What JexePack is: JexePack is a command line tool (great for automated scripting) that allows you to package your Java application (class files), optionally along with its resources (like GIF/JPG/TXT/etc), into a single compressed 32-bit Windows EXE, which runs using Sun's Java Runtime Environment. Both console and windowed applications are supported.
Java application to Windows EXE: JexePack turns the Java platform into a transparent technology instead of a technology your customers need to know about -- a great way to deploy Java applications on the Windows platform. A single double-click launches your Java application, and you get to define the EXE icon. And Java can be automatically installed, if needed.
JexePack embraces Java technology: Your Java program is still 'all Java' and is still being run under Sun's Java VM. You are just deploying your Java program as a native EXE. It just makes a lot of sense to deploy your application in a format that is native to the Windows OS. And if your Java program is a tool that might be integrated into other programs, having an EXE to "exec" is crucial.

Windows NT Service: An EXE is especially critically important if you want to deploy your Java code as a Windows NT service! We have helped many companies deploy Java NT services. Just contact us for details and sample code.

Protecting Intellectual Property: JexePack does add an extra layer of packaging to your code, so it makes it just a little harder for casual hackers to find your Java class files. However, we strongly recommend that if protecting your code is an issue, that you use an obfuscator tool (such as Jobfuscate) to help protect your Java class files from a decompiler and reverse engineering.

Runtime Versions: JexePack supports Sun's Java Runtime Environment 1.5 and later. To help ensure that the correct Java version is selected to run your application at runtime, a minimum "java.version" may be enforced (see /minver [§3]) as well as a maximum "java.version" (see /maxver [§3]). If a Java is not installed (or the version you need is not installed), Java can be automatically installed. (refer to the /getjava [§3] command line option). Or, if your prefer to package your EXE with a private java runtime, review the /jvm [§3] command line option.

Feature Summary:
  • Your application is packaged into a single EXE, with an icon you define
  • Native EXE allows for better system integration (icon, double-click, shortcuts, etc)
  • Packaged classes and resources are compressed, so the EXE footprint is the smallest possible
  • You can target a very specific public Java runtime version, or a private JRE
  • Full support for JNI (Java Native Interface) DLL's
  • Full support for loading/finding classes at run-time
  • Added EXE overhead is ultra-small
  • Automatic JRE installation (see /getjava [§3]) when Java is not installed
Program Requirements: Microsoft Windows 10/8/7/Vista/XP/2003/2000/Me/98; Sun's Java Runtime Environment 1.5 (or later) installed.
  2. Using JexePack
Example: Here is an example of how we at Duckware use JexePack for all of our applications:
jexepack.exe @jexepack.ini
Instead of specifying options on the command line itself, options are instead moved into an INI file. For example, here is the jexepack.ini for our VirtualTourEditor program:
# JexePack command line options
/appname:Virtual Tour Editor
Trial Examples: The trial download (button at the top of this page) contains Several simple example Java programs. Please review these simple applications, the build files included, and this entire manual, for examples on how to use JexePack.

JexePack is itself a Win32 console application, which allows it to be easily integrated into scripts and Java development environments. Before deploying a generated EXE, please first review the Deployment Checklist [§10].

Command Line Help: When JexePack is run with no arguments from a console window (DOS prompt), the following help is displayed:

Duckware (R) JexePack (TM) Registered Version 8.4a (build 4781)
Copyright (c) 2000-2013 Duckware. All rights reserved.

Typical usage: jexepack /main:<clname> {[/options] file-spec}*

Add all files (class/jar/gif/jpg/etc) via these options:

  file-spec        filename (eg: dns.class) or wildcard (eg: *.class)
  @<command-file>  each line in file treated as a a command line option
  /dir:<dir>       look for following 'file-spec' in another directory
  /pre:<dir>       adds directory prefix to packaged 'file-spec'
  /r               recurse into sub-directories looking for 'file-spec'
  /r-              do not recurse [default]

Options that affect the EXE created:

  /out:<exe>       names EXE output file (defaults to <main-clname>.exe)
  /appname:<name>  name of application, used in title of error message dialogs
  /icon:<file>     sets the EXE application icon (file must be an .ICO)
  /verinfo:<file>  adds VS_VERSION_INFO into EXE from simple 'key=value' file
  /vista:<level>   Vista: 'asInvoker|highestAvailable|requireAdministrator'
  /manifest:<file> Vista: binds <file> into EXE as the app RT_MANIFEST
  /cwd2exe         forces 'current working directory' to exe folder at run-time
  /windowed        create a GUI windowed app (otherwise console app)

Options that determine which JVM the EXE selects at run-time:

  /minver:<ver>    minimum 'java.version' (>=1.5) your java app requires
  /maxver:<ver>    maximum 'java.version' (rarely used)
  /jvm:<dll>       try EXE relative JVM (eg: /jvm:jre\bin\client\jvm.dll) first
  /getjava:<exe>   java installer run when no JVM match is found (* = latest)

Options that affect the Java run-time environment:

  /main:<clname>   class name with 'main()' function, as in 'java <clname>'
  /mx:<meg>        sets maximum JVM heap size (in megabytes)
  /cp:<options>    java.class.path list: resdir+exedir+classpath+cwd+none
  /lp:<options>    java.library.path list: resdir+exedir+path+cwd+none
  /J<option>       JVM option: /JDname=value, /JXincgc, /JXbatch, etc
  /ljar:<jar>      adds EXE relative JAR to classpath (eg: /ljar:jars\io.jar)
  /novmabortmsg    suppresses JVM aborting warning message
  /classloader:<clname> loads app 'main' class via named classloader

Other options:

  /build:<dd-mmm-yyyy> adds EXE build number as java '' property
  /0                   turn option consistency checking off

For help and usage examples, refer to the online manual at:

Java Version: At runtime, JexePack will search for a JRE that satisfies the minimum and maximum "java.version" (refer to /minver and /maxver [§3] option). Your code will be run under the JRE with the most recent "java.verion" (as long at it matches you min/max criteria). Or use /jvm [§3] to reference a private JRE alongside your EXE.

JAR Files: Any 'JAR' file(s) that you package into the EXE will automatically be added into the java.class.path at runtime. Or keep your JAR files outside the EXE and use the /ljar:<file> [§3] command line option to include them class path at runtime.

GIF/JPG/etc files: Use Java's built-in getResource() mechanism of accessing resources in JAR files. Or, to access a GIF, JPG, or other (read-only) file that you have packaged directly into the EXE (not inside a JAR), refer to Understanding Directories [§8]. The "MyFrame" example application in the trial download provides an example on how to access a packaged GIF file.

Windowed Applications: If you are creating a windowed Java application (and not just a console application), be sure to add a "/windowed" [§3] to the command line, which tells JexePack that your application is a windowed application (which eliminates the DOS console window). For example:
jexepack /windowed /main:MyFrame /dir:c:\test /r *.*
Packaging Large Applications TIP: Get your Java application working in an isolated directory (eg: c:\test) first, potentially testing under multiple JRE versions. Once you know that your application works properly, just use JexePack to package all files in that directory, making sure to specify a /main [§3] class file and the proper minimum Java version required. For example:
jexepack /main:MyApp /minver:1.5 /dir:c:\test /r *.*
Exit Codes: To allow JexePack to be used with batch processing environments, the exit codes of JexePack are: 2=errors, 1=warnings, 0=OK.

Remember to review the Deployment Checklist [§10] before releasing a JexePack generated EXE to your clients.
  3. JexePack Command Line Options
Usage: jexepack /main:<clname> {[/options] file-spec}*

/MAIN:<clname> - This option is required. Specifies the name of the main class. Note that the class as well as the main function must both be declared public. Usage examples:
jexepack /main:SysProp *.class
jexepack / /r *.class
/DIR:<dir> - Look for "file-spec" in a directory other than the current directory. Allows you to package files from a named directory or folder. This option may be used multiple times with "file-spec" to add files from multiple locations. Usage examples:
jexepack /main:Test /dir:classes *.class /dir:images *.gif
jexepack /main:Test /dir:..\dns /r *.class *.gif
jexepack /main:Test "/dir:c:\My Documents\java\dns" /r *.*
/MINVER:<ver> - Specifies the minimum "java.version" that your Java code requires The <ver> syntax is usually #.# (eg: 1.5), #.#.# (eg: 1.4.2), or #.#.#_## (eg: 1.4.2_10). It is strongly recommended that you always specify a reasonable minimum java version to prevent runtime errors when someone tries to run your EXE on a computer with an old Java VM (and use /getjava for automatic Java VM installation). Usage examples:
jexepack /main:Test /minver:1.4.2 *.class
jexepack /main:Test /minver:1.5 *.class
/MAXVER:<ver> - Specifies the maximum "java.version" that your Java code can use. The <ver> syntax is usually #.# (eg: 1.5), #.#.# (eg: 1.4.2), or #.#.#_## (eg: 1.4.2_10). If used, almost always used in conjunction with /minver. WARNING: If you use /maxver, do not use /getjava:* -- see /getjava for more information.

/OUT:<exe> - Names the output EXE that JexePack generates. The full EXE name, including the .exe extension, must be specified. Usage example:
jexepack /main:Boot /out:SysProp.exe *.class
/ICON:<file> - Specifies the ICO icon file that is used as the application icon in the generated EXE. The icon is embedded as a resource into the Win32 EXE and does not need to be added to the files list. [2.1a] Usage examples:
jexepack /main:Test /icon:../app.ico *.class
jexepack /main:Twister /icon:twister.ico *.class
jexepack /main:dns /icon:c:\ico\dns.ico *.class
/GETJAVA:<exe> - Specifies the EXE (in the local file system) to be packaged into the EXE and automatically run when there is not an appropriate version of Java found on a clients computer. This EXE may be a custom EXE that you write, but is almost always Sun's online installation EXE (around 373K) found on Sun's Manual Download web page [5.1a] Usage examples:
jexepack /main:dns /getjava:c:\java\getjava142.exe dns.class
Note: New to 5.2a is the ability to specify the asterisk (*) for the filename. This causes JexePack to automatically download, which is a redirection to Sun's latest online installer (which is almost always wanted):
jexepack /main:dns /getjava:* dns.class
However, if you want to use an older Java installer, see Sun's product download archive. Just obtain the online JRE installer for the version of Java that you want to use. Please note that if /maxver is used that /getjava:* should NOT be used. Here is an example of the problem:
# ERROR: want Java 1.5, but 'getjava' references latest (Java 1.6)
/APPNAME:<name> - Allows you to specify the name of your application -- for use in error dialogs during startup. Usage examples:
jexepack /main:Boot /appname:MyFrame *.class
/LJAR:<file> - Adds a JAR file into the CLASSPATH at runtime that has not been packaged into the EXE. The <file> is expected to be relative to wherever the EXE is located (in the same folder or a sub-folder). [3.4a] Usage example:
jexepack /main:dns /ljar:jars\dns.jar ...
/PRE:<dir> - Prepend the named directory to the output file-spec. Allows you to place packaged file-spec [§3] into the named output directory in the packaged EXE. [1.0c] Usage example:
java /main:Test *.class /pre:src test.txt
(adds test.txt into the EXE as src\test.txt)

/J<option> - Allows you to configure advanced java command line options. [2.3a] Usage example:
jexepack /main:NTService /JXrs *.class
which turns on 'reduce use of OS signals by Java/VM'. The following variables are available and substituted at run-time:
/j<option> substitution variables
$EXEDIR$folder¹ where packaged EXE is being run
$RESDIR$folder¹ where package resources have been extracted
$JAVAHOME$folder¹ where Java resides (JAVA_HOME)
¹Folder name without trailing backslash
For example:
jexepack /main:test /JXloggc:$EXEDIR$\gc.log *.class
/BUILD:<date> - Allows you to have JexePack automatically keep track of the 'build' number for your EXE. Just specify the date you started coding on a project (in dd-mmm-yyyy format) and JexePack will automically calculate a build number as a new Java system property "". The build number is the number of days from the EXE creation to the specified date. [2.4a] Usage example:
jexepack /main:Test /build:27-Jul-2000 *.class
/mx:<meg> - Configures the maximum amount of memory that your java application can use when running under Sun's java.exe. [3.7a] Usage example:
jexepack /main:Test /mx:512 *.class
/jvm:<dll> - Configure a 'private Java VM' to use. Instead of using a public Java VM installed on the local computer, this options allows you to use a custom JAVA VM that is packaged along with your application. The DLL must be an EXE relative path, and is usually installed in a sub-folder next to the EXE. [7.0a] Usage example:
jexepack /main:Test /jvm:jre\bin\client\jvm.dll *.class
/CP:<options> - sets the java.class.path to one/any of "resdir+exedir+classpath+cwd+none". For security reasons, the CP defaults to just 'resdir'. [8.0c] Usage example:
jexepack /main:Test /cp:resdir+exedir *.class

/LP:<options> - sets the java.library.path to one/any of "resdir+exedir+path+cwd+none". For security reasons, the LP defaults to just 'resdir+exedir'. [8.0c] Usage example:
jexepack /main:Test /lp:resdir *.class *.dll

/CWD2EXE - forces JexePack to set the 'current working directory' to the EXE directory at runtime. Refer to understanding directories [§8] for more details. [8.0c] Usage example:
jexepack /main:Test /cwd2exe *.class
/WINDOWED - Creates a windowed/GUI application, which eliminates the DOS console window. TIP: During development, test your application without "/WINDOWED" to ensure that you see all error messages (in a DOS console window) produced by Java and your application. Usage example:
jexepack /windowed /main:MyFrame *.class
/R - Recurse into directories looking for file-spec [§3]. Most large applications will have class files in multiple directories (packages), so using a wildcard file-spec will find all class files in any subdirectories. Usage example:
jexepack /main:Test *.txt /r *.class
/R- - Do not recurse into directories looking for file-spec (the default). [1.0c] Usage example:
jexepack /main:Test /r *.class /r- *.gif
/0 - Turns off command line option consistency checking (note: this option is the number zero, not the letter O). JexePack attempts to validate and verify correct command line option usage and will display warning messages if it feels they are being used improperly. This option turns off that checking. [2.0a] Usage example:
jexepack /0 options /main:Test *.class
/vista:<asInvoker|highestAvailable|requireAdministrator> - JexePack create a basic manifest file with the specified requested execution elevation level. This manifest tells Windows that you know your EXE is 'Microsoft Windows Vista aware'. [6.4a] Usage example:
jexepack /vista:requireAdministrator options /main:Test *.class
When Windows Vista encounters an EXE that does not have a Vista manifest, that EXE is run in 'legacy mode'. Vista performs hard drive and registry virtualization that allows the EXE to perform questionable actions, like write files into C:\Program Files\. However, tight security and locking down computers is here now, so it is highly recommended that you mark your application as Vista aware and fix any security issues with your application.

/verinfo:<file> - Specifies that a VS_VERSINO_INFO should be added into the EXE from a file of simple 'key=value' lines. The file can be either ASCII or Unicode. Refer to the sample 'MyFrame' project in the trial download for a usage example. Typical 'keys' are Comments, CompanyName, FileDescription, FileVersion, InternalName, LegalCopyright, LegalTrademarks, OriginalFilename, ProductName, ProductVersion, etc. [7.4a] Usage example:
jexepack /verinfo:vsversioninfo.txt options /main:MyFrame *.class
with a vsversioninfo.txt file that looks like:
/manifest:<file> - Allows you to specify a manifest file to be bound into the application as the Windows RT_MANIFEST resource type. [6.4a] Usage example:
jexepack /manifest:MakeInstall.manifest options /main:Test *.class
@<command-file> - Each line in the named text file is processed as a JexePack command line option or file-spec. Lines in this file that start with # are treated as comment lines. This is very useful when the number of options is very large and do not fit into a single DOS command line. [1.3a] Usage example:
jexepack @dns.ini
Where file "dns.ini" might look like:
# JexePack config file
Please note that JexePack version 2.3a (and prior) does not like blank lines in the config file. Version 2.3b (and later) will ignore any blank lines.

file-spec - A file name (eg: dns.class) or wild-card file specification (eg: *.class or *.gif, etc) for files to be packaged into the EXE. Specify multiple times to add multiple files. To add files from another directory or folder on your computer, combine usage with the /dir: [§3] option. Usage examples:
jexepack options *.class *.gif *.jpg
jexepack options *.class options *.jar
jexepack options *.gif /dir:..\ip2ns ip2ns.jar
You can package any file type (not just class files) into your EXE. This allows you to package read-only files/resources (like GIF/JPG images, etc) which can then be accessed at run-time by your Java program. Refer to Understanding Directories [§8] for details.

Please note that the packaged resources are extracted into a temporary directory that are deleted once your program exits. Consider packaged resources as read-only resources that should not be modified. Really slick because your users only see a single EXE!
  4. 'How To' Guide
How do I get started using JexePack?
The best way is to review the sample applications in the trial download, using this manual as a reference guide. Review the Java source code and the JexePack build process (make.bat) for each of the sample applications.
TIP: Start out by packaging only your .class files into an EXE. Then, if desired, gradually move other resources, like images, etc into the EXE. See the next question for detailed help.
How do I access a packaged GIF/JPG resource file?
Use the standard Java mechanisms for accessing resources located in JAR files.

However, if some of your resources are external to JAR files and packaged into the EXE, those resources are available in the temporary directory that JexePack extracts your packaged files into. Review 'Understand Directories' [§8] and resDir() for details. Also, the MyFrame application in the trial download has an example of accessing a packaged GIF.
How do I access files located in the EXE directory?
Resource files that you ship along with your EXE, that are not packaged into the EXE can be accessed normally. But, be careful to avoid the situation where the 'current working directory' is not set to the 'EXE directory'. Review 'Understand Directories' [§8] and exeDir() for details.
How do I set Java 'system properties' (-Dproperty=value) on the command line?
Your Java program is passed the entire EXE command line, so this is something that you can implement yourself. Please review the SysProp application in the trial download, which has a reference implementation of setting system properties from the command line -- which is code you are allowed to copy and paste into your application.
Note: Setting system properties on the command line is not very user friendly, especially for GUI applications. So, coding a configuration dialog in your application is preferred.
How do I access Operating System environment variables?
You should probably rewrite your Java code to avoid having to use a native OS environment variables. A good alternative is to code a configuration dialog into your application. If you still require access to environment variables, you can access them by writing a JNI function.
How do I access my application's 'Property' configuration file?
You will probably want to create/access a Property file that is located in the 'user.home' folder. For example:
File home = new File(System.getProperty("user.home"));
File appdir = new File(home,"your-app-name");
File config = new File(appdir,"config.ini")
How do I package and access my JNI DLL?
Just package your DLL into the EXE into the root level (not in a sub folder) as a file. Refer to the file-spec [§3]) command line option. JexePack will then ensure that the Java VM will find your JNI DLL.
How do I set an icon for my EXE?
Use the /icon:<file> [§3] command line option. This is usually only done for GUI applications (and not console applications).
How do I prevent my program from running under an old JRE?
Use the /minver:<ver> [§3] command line option to configure the minimum java.version that your program requires. Also, specify a /getjava:* so that the most recent JRE installer will be bound to your EXE, and Java automatically installed, as needed.
How do I eliminate the DOS console window for my windowed application?
Use the /windowed [§3] command line option to create a 'windowed' (GUI) application.
How do I prevent Java "Out of Memory" run-time errors?
JexePack defaults the maximum memory to 256 MB. Use the /mx:<meg> [§3] command line option to configure different maximum memory setting.
How do I use my License Management tool to protect the EXE?
That is fully supported. Just use your License Management tool like you do today on the JexePack generated EXE.
Can I deploy my EXE as a Windows NT Service?
Sure, but you will need some additional Java and native code which communicates with Windows NT to implement the service. Just contact us for details and sample code.
If Java is not installed (or the wrong version), can my EXE automatically install Java?
Yes, just use the /getjava [§3] command line option to specify the Java installer that you want to run in that situation.
Can I force my packaged application to run under a very specific version of Java?
Private Java VM Method: Package a complete private Java VM with your EXE. Your installer will install your application as well as your Java VM into your installation folder. Refer to the /jvm:<dll> option for details.

Public Java VM Method: Otherwise, to use a specific public Java VM, use /MINVER, /MAXVER, and /GETJAVA like this:
jexepack @usejava142_06.ini /main:SysProp *.class

Where you obtained the j2re-1_4_2_06-windows-i586-p-iftw.exe Java installer from Sun's product download archive. The result is that your app is run only under Java 1.4.2_06, and if that version of Java is not found, it will be automatically installed for use by your app. You can be as specific (or general) as you want. For example, "1.4.2_06" above could have been "1.4.2" (any 1.4.2 build), "1.4" (any 1.4.x version), etc.
  5. Case Study
Packaging a third party server tool into an EXE by using JexePack

Your slick Java application requires a third party server tool in order to run. However, this third party tool was designed to be run via a BAT file as follows:
SET INSTALLDIR=full-installation-path
SET JAVABIN=full-java13bin-path
%JAVABIN%\java.exe -DQVA_PROPS_FILE="%INSTALLDIR%\config.ini"
  -classpath "%INSTALLDIR%\jar\qvaserver.jar";
The obvious huge problem with this BAT file is that it requires someone (the end user) to configure hard coded folder path locations (the installation folder and the location of the Java installation folder) before the third party tool can be run for the very first time.

This is horrible. It requires someone's time to configure the tool before it can even be used the first time. It is error prone since the full pathanme to folders on the computer must be typed in by hand. There must be a better way to eliminate all of this.

The solution is to use JexePack!
  • Let JexePack find and run java.exe (with Java 1.3 version checks)
  • Use the /ljar:<file> [§3] command line option to reference the local JAR files.
  • Use the /J<option> [§3] command line option set non-standard java.exe options
  • Write a small bootstrap loader to set the QVA_PROPS_FILE system property and then run the main class file. (It is a bad practice to use system properties to locate configuration files, but in this case, the source code to the third party tool was not available to change)

So, the final solution to this problem is to use the following JexePack INI command line options file:
with a file that looks like:
public class BootQVA {
  public static void main( String[] args ) throws Exception {
    String file = new File(exeDir(),"config.ini").toString();
    setSystemProp( "QVA_PROPS_FILE", file );
    Class cl = Class.forName("com.qva.DDServer.Main.TheServer")
    Method m = cl.getMethod("main", new Class[]{String[].class});
    m.invoke( null, new Object[]{m_args} );
where setSystemProp() and exeDir() are functions whose code can be obtained from the sample SysProp program in the JexePack trial download. Since we need to set a system property before the real program is run, we do so and use reflection to run the true main class file after we are done.

The resulting EXE is now simply a click-and-go product with no configuration needed!
  6. How JexePack works
When your EXE is run, JexePack extracts all of the packaged files into a temporary resource directory, defines a java.class.path, modifies the PATH, and runs your Java program with an appropriate Java VM found at run-time. When your program exits, the temporary directory is cleaned up (deleted).

JAR Resources: If your resources are bundled within a JAR file, use Java's "getResource()" and "getResourceAsStream()" functions to access your resources. Please refer to Sun's documentation for details.

Temporary Resource Directory: JexePack extracts all of the packaged files into a temporary resource directory. So, all file-spec [§3] files -- like class, JAR, JNI DLL, GIF, JPG, etc -- are extracted into the temporary resource directory for you (and the Java VM) to access.

Accessing Files: Please review 'Understand Directories' [§8] for help in accessing files located in the various directories. For accessing files that you packaged into the EXE, review the "resDir()" function. For accessing files that you ship along with your EXE, review the "exeDir()" function.

Command Line Arguments: Any command line arguments passed to the packaged EXE will be automatically forwarded to the main() entry point in your Java application. Please refer to the "SysProp" application in the trial download for an example. If you want to pass an argument that contains spaces, just quote the entire argument, like:
SysProp.exe arg0 "argument 1 with spaces" arg2
  7. jWalker - Integrated debug support and stack traces
jWalker helps you to track down deadlocks/hangs in your Java code in a JexePack generated EXE's by generating full stack trace dumps on demand. Have you been unable to reproduce a hang in your Java code running at a client site? And once the hang happens, it is too late to run your code in debug mode. The solution is jWalker!
Every EXE generated by JexePack comes with jWalker support. Just run jWalker, find your application in the list, click the button, and you have an instant stack trace of all threads running inside the Java VM.
jWalker output
Essentially, jWalker adds CTRL-break (CTRL-\) support into your application, even if it is a GUI application.
  8. Understanding Directories and accessing your files
Background: It is important to understand that it is possible for Java to run your application such that the 'current working directory' is different from the directory where your class files (and application configuration files) are located. Consider the following:
cd c:\test
set CLASSPATH=c:\javaapp
In this case, the current working directory is c:\test, but your Java class files are located in c:\javaapp. This exact same behavior can also happen when your program is packaged into an EXE. And actually, this is an important and desired behavior if your program is a tool that is installed into the PATH of the computer system.

For example, if your EXE is installed or placed into a directory which is also included in the PATH, (eg: c:\exes\yourapp.exe), the end user can be in another directory (eg: c:\test) and run your application by just typing the name of the application ('yourapp.exe'). In this case, the 'current working directory' will be the current directory (c:\test\), which is not the location of your EXE (eg: c:\exes\).
TIP: If you want to force the 'current working directory' to be set to the EXE directory, just use the new /cwd2exe [§3] command line option. This can help to convert legacy Java applications to a JexePack EXE since some legacy applications can not handle a 'current working directory' that is different than the EXE folder location.
Then, on top of this, JexePack adds the concept of the 'packaged resources' directory, so you now have three directories to understand and work with.
NOTE: If you do not package application resources (GIF,JPG,etc) into your EXE, then you do not have to work with a 'packaged resources' directory.
Dual-Mode Access: Most often during the development of your Java application, you will be testing it outside of JexePack -- and only using JexePack to deploy your application. But it is important that your Java code does not have to change to handle this situation. So, it is best to write your directory discovery functions to work whether or not your Java application is packaged. The following functions are written to assume that if your Java application is not packaged, all of your files are located in the 'current working directory'.

Directory Functions: The functions you can use to access your directories are as follows:

  1. Current working directory. The Java system property "user.dir" is the full path name to the current working directory. You can also use "." to represent the current working directory. To access the current working directory, use code similar to:
public static File cwd() {
  return new File(System.getProperty("user.dir","."));
2. Temporary resources directory. Any file packaged into the JexePack EXE is extracted at runtime into a temporary working directory. The full path name to the directory containing these read-only files can be accessed by using the JexePack system property "jexepack.resdir" as follows (if your app is not packaged into an EXE, the current working directory is returned):
public static File resDir() {
  String p = System.getProperty("jexepack.resdir");
  return (p!=null) ? new File(p) : cwd();
3. EXE directory. The full pathname of the EXE being run is contained within the JexePack system property "jexepack.exe", so you can obtain the EXE directory with code similar to the following (if your app is not packaged into an EXE, the current working directory is returned):
public static File exeDir() {
  String p = System.getProperty("jexepack.exe");
  return (p!=null) ? new File(new File(p).getParent()) : cwd();
Accessing Files: Files passed to your Java program on the command line can be accessed based from the "cwd" directory. Files packaged into the EXE can be accessed based from the "resDir" directory. Files shipped and installed along with your EXE and located in the EXE directory can be accessed based from the "exeDir()" directory.
  9. Trouble Shooting Guide
If you are running into problems, follow the tips in this trouble shooting guide. Also, review the Technical Notes [§11]. If problems persist, please contact us with details.

Review the Deployment Checklist: Have you reviewed the Deployment Checklist [§10]?

Is JexePack producing warnings or errors? JexePack attempts to validate command line usage -- and if it thinks something is not being used properly, a warning message is output. Are you producing an EXE without warnings or errors? If not, review and correct the problem.

JexePack is unable to find the /main class? Please note that all of the class files that you add into the EXE must be added into the proper 'Java package'. Namely, if you have class files located in package "", then you must add those classes into the EXE as "com\duck\awt\*.class". Likewise, if your classes are in the 'default package', the class files must be added into the EXE at the root level, like "*.class", and not in a folder, like "classes\*.class", which implies a 'Java package' of "classes".

Accessing packaged resources and other files: Remember that resources packaged into the EXE must be considered read-only resources. The packaged resources are accessible in the "jexepack.resdir" directory, a system property. See Understanding Directories [§8] for details.

Java version: Are you specifying the minimum "java.version" that your program requires via the "/minver:<ver>" [§3] command line option? TIP: Go into a DOS window and type "java -version" to see the version of Sun's Java installed.

Review Program / Java VM Output: Capture your program's output [§9.1] and review for any messages (from the Java VM; from library code, etc) that something is going wrong.

  9.1 Capturing Program Output for Debugging
Review the Java VM output for error messages: Many times, the Java VM will output an error message and stack trace when something goes wrong -- like a "class not found", or something similar. If your program is a GUI application, remove the "/windowed" [§3] option from the command line to temporarily create a console application (for debugging purposes only) so that you can review any output from the Java VM. Carefully review any error messages and correct any problems.

TIP: Even with a Windowed application, you can still use the DOS redirection 'greater than sign' to capture the 'standard output' stream (System.out) of your Windowed program! For example, type the following from within a DOS command prompt window:
dns.exe >output.txt
Any 'standard output' from dns.exe will be redirected and captured into file output.txt. However, please note that this does not capture the 'standard error' stream (System.err) from your application (the Java VM outputs many errors to the 'standard error' stream). To also capture 'standard error', use the special -E* command line switch (a feature of any JexePack generated EXE), which will redirect the standard error stream to standard output, so it can be captured. For example:
dns.exe -E* >output.txt
Please note that the JexePack EXE itself will process the -E* command line switch and will not forward it to your application. [2.2a]

A note about Vista: When running an EXE marked as "/vista:requireAdministrator", in order to successfully capture program output, you must be in a Administrator DOS window. This is a security feature of Vista and just how Vista works. Namely, a 'normal' DOS window (low security) is not allowed to capture output from an Administrator (high security) program.
  10. Deployment Checklist
Before deploying a JexePack generated EXE to your customers, please review this important checklist:

1. Java Version: Does your program work under Java 1.5? If not make sure to specify the minimum Java version that your program requires by using the /minver [§3] command line option.

2. EXE Icon: Make sure that you specify an EXE icon for your windowed applications via the /icon [§3] command line option. This just makes your application look a lot more professional.

3. Automatic Java VM installation: Make sure that you use the /getjava [§3] feature to specify an EXE to run (like Sun's online Java installation EXE) when an appropriate Java VM can not be found.

4. Vista compatibility: Review /vista [§3] and /manifest [§3] and if your application is Microsoft Windows Vista aware and compatible, make sure to mark it as such. If an EXE is not marked as 'Vista aware', Vista virtualizes certain hard drive and registry access, which you may or may not want.
  11. Technical Notes
Naming JNI DLL's - When you name and package your JNI DLL into a JexePack EXE, make sure that your DLL name is unique and does not conflict with any other DLL name from any other Java vendor. The Java docs do not document this well, but DLL's in the Windows system folders may be found first, so if another vendor has (incorrectly) installed a DLL into a Windows system folder, which is named the same as your DLL, your DLL will not be found. So, include your company name (or other relatively unique name) in the filename of your JNI DLL. It is also recommended that you include some type of version number in the naming of your JNI DLL.

Inner Classes - Remember that any inner classes generated by your Java compiler must also be packaged into the EXE, otherwise you will get 'class not found' errors when your program is run. For example,, which implements a window listener, will produce Test.class, and possibly an inner class file named Test$1.class, when compiled.

  12. How to register and pay for JexePack?
JexePack is shareware. Please try it for free (download link at the very top of this web page). If you like it enough to keep using it, you must pay for this program. An "Unregistered Version" reminder will be displayed every time a packaged EXE is run until you purchase a license:
JexePack is no longer available for purchase
Please refer to the license usage information page for details. EXE's generated with a registered JexePack in accordance with the license [§13] can be distributed royalty free.
  13. No Nonsense License Agreement
JexePack is shareware. That means that you may try it for free to see if it works for you. If you like the software enough to keep using it, you must pay for it. If you find anything wrong with the software, let me know and I will try to fix the problem immediately. My entire liability for your use of this software shall not exceed the amount you paid for the software. You may not reverse engineer or decompile the software. You may not modify the software in any way. The software may not be used on adult sites nor to display adult material. License violations will result in license termination, forfeiture of license fees, and possible prosecution.

EXE's generated with a registered JexePack, in accordance with this license, can be distributed royalty free.
  14. Release History
Version/Date    Changes made in release
8.4a - 08/29/2013  · Java 7u21 compatibility work
8.3a - 04/04/2012  · change how quoted arguments are parsed
8.0c - 02/25/2009  · Java 1.4.2 is now the minimum Java version supported
· new -cp (java.class.path) and -lp (java.library.path)
· new /classloader
· renamed /execwd to /cwd2exe
· replace /jop with -J<option>
· works around Java Unicode bugs; new internal Unicode model
· revamped security
7.4a - 09/29/2008  · add VS_VERSION_INFO capability to EXE via /verinfo
7.3b - 09/25/2008  · uses updated installer
7.3a - 05/29/2008  · EXE's produced allow for '-mx:###' command line argument
7.2a - 10/21/2007  · work around msvcr71.dll dependency issue in Sun's JVM.DLL details
· jWalker support (integrated stack traces)
7.1c - 10/09/2007  · misc debug prints in C bootstrap loader
7.0c - 10/01/2007  · add /appname
7.0b - 09/19/2007  · Added /vista:<type> support (replaces /administrator)
· Changed when 'Unregistered' popup happens
7.0a - 09/17/2007  · Reduced memory overhead when creating / loading an EXE
· Loader uses memory mapped file to access EXE
· Vista /manifest:<file> support
· JexePack install folder is added to environment PATH variable
· private Java VM support via /jvm:<dll>
6.3a - 09/11/2007  · If Java installer in EXE fails, user is redirected to Sun's web site to install Java
6.1a - 12/27/2006  · Fixed stderr (-E*) redirection issue with 6.0a
6.0a - 09/02/2006  · Supports launching Sun's JRE via JNI (removed jview VM support)
· Enhanced error messages removes need for /helpurl option
· Automatic JAR handling (removes need for /jar option)
· removed /target (always set to 'java' now)
· removed /v (always turned on)
· removed /nosign (always turned on)
5.7b - 07/31/2006  · various updates for private clients
5.6a - 02/17/2006  · exe signed by 'Duckware'
5.5a - 12/19/2005  · uses modified packager
5.4a - 11/29/2005  · removed need for the /JNI command line option
5.2b - 11/14/2005  · Allow '*' for /getjava filename (auto downloads Sun's installer)
5.1a - 09/26/2005  · /getjava support for automatic Java VM installation
· Increased helpurl maximum length from 64 to 128 chars
4.1a - 04/12/2004  · fixed non-GUI console app 16-color/DirectDraw issue with java.exe
4.0a - 01/29/2004  · Released with NT Service TestService.exe sample app
3.7a - 01/27/2004  · added /mx:meg option
3.6b - 11/17/2003  · when 'java.exe' is used, the maximum memory defaults to 256M
3.6a - 10/28/2003  · when 'java.exe' is used, the maximum memory is the larger of (a) 256M or (b) physical memory
· added more debug output (with timing information)
3.5a - 10/12/2003  · better automated 'minver' checking based upon class file version
3.4c - 06/25/2003  · handles a CLASSPATH with special chars better
3.4b - 04/09/2003  · added /execwd to force 'current working directory' to exe directory
3.4a - 02/11/2003  · added /ljar option
· When java is used, the default memory option is '-mx256m'
3.2a - 08/30/2002  · binjava /target now runs "jre\bin\java"
· /target is now an ordered list of Java VMs
3.1a - 07/02/2002  · added /nosign to allow 3rd party tools to protect EXE
3.0b - 06/07/2002  · renamed J2EXE to JexePack
3.0a - 06/02/2002  · renamed Java2exe to J2EXE
2.5a - 04/28/2002  · Support the binjava Java VM target (runs bin\java)
2.4c - 04/24/2002  · fix stdin/stdout windowed app issue on NT/2000/XP systems
2.4b - 03/29/2002  · When java/jre is used, the default memory option is '-mx128m'
2.4a - 01/30/2002  · use 64-bit EXE digital signatures (previously 32-bit)
· EXE dir is now last in the CLASSPATH (was first)
· added /build option
2.3d - 01/16/2002  · Added jexepack.exe system property
2.3c - 11/19/2001  · add EXE directory to CLASSPATH, so dynamic classes are found
· allow blank lines in @<file> config file
2.3a - 10/06/2001  · Sun's java.exe memory/stack options configurable via /jop
· automatic detection of JNI DLL usage
2.2a - 07/27/2001  · Java Native Interface (JNI) DLL support
2.1a - 07/16/2001  · support for EXE icons (/icon command line option)
· automatic detection of javax.swing.* package usage
2.0a - 07/07/2001  · more error checking of the command line arguments
1.3a - 06/06/2001  · added @<file> command line option
· improved jar file management
1.2b - 05/26/2001  · progress bar now displayed while unpackaging large applications
· EXE contains digital signature checks to detect tampering (by viruses, etc)
1.0c - 08/15/2000  · full install/uninstall support
1.0b - 07/31/2000  · added support for Sun's java and jre
1.0a - 07/27/2000  · supports Microsoft's jview Java VM
· first public release of Java2exe
  15. How to Modify the PATH environment variable
Installing JexePack should automatically add the jexepack.exe installation folder into the PATH environment variable on Windows Vista/XP/2003/2000/NT.

Windows Vista/XP/2003/2000/NT: Right click on My Computer and select Properties; Select Advanced tab; Click on the Environment Variables button; Select the PATH variable; Click on the Edit button.

Windows ME: Go to Start / Run / 'msconfig'; Select the 'Environment' tab; Select the PATH variable; Click on the Edit button.

Windows 98: Find "c:\autoexec.bat" within Windows Explorer; Right click on the file; Select 'Edit'; Modify the "SET PATH=paths line that you see; Then reboot your computer.

Copyright © 2000-2024 Duckware