| |
JexePack 8.4a
JavaTM application to EXE packager
(previously named Java2exe)
| |
|
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.
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
/windowed
/build:02-Dec-2004
/icon:vte.ico
/mx:400
/cwd2exe
/getjava:*
/main:VirtualTourEditor
/vista:asInvoker
vte.jar
images\*.gif
images\*.jpg
/dir:..\Win32\dll
*.dll
|
|
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 'jexepack.build' property
/0 turn option consistency checking off
For help and usage examples, refer to the online manual at:
http://www.duckware.com/jexepack/index.html
|
|
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 /main:com.duckware.net.ReadURL /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
http://www.duckware.com/download/getjava.exe,
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)
/minver:1.5
/maxver:1.5
/getjava:*
|
|
/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
"jexepack.build". 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:
; VS_VERSION_INFO
CompanyName=Duckware
FileVersion=7.4.0.2986
ProductVersion=7.4.0.2986
|
|
/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:
Where file "dns.ini" might look like:
# JexePack config file
/dir:c:\java\dns
/main:dns
*.class
*.gif
|
|
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!
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
usejava142_06.ini |
/minver:1.4.2_06
/maxver:1.4.2_06
/getjava:c:\java\j2re-1_4_2_06-windows-i586-p-iftw.exe
|
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.
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";
"%INSTALLDIR%\jar\qvanet.jar";
"%INSTALLDIR%\jar\qvacommon.jar";
"%INSTALLDIR%\jar\qvautil.jar";
"%INSTALLDIR%\jar\cryptix32.jar";
"%INSTALLDIR%\jar\log4j.jar"
-Xmx400m
-DMEM_SIZE=400
-Xrs
com.qva.DDServer.Main.TheServer
|
|
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:
/main:BootQVA
/minver:1.4.2
/ljar:jar\qvaserver.jar
/ljar:jar\qvanet.jar
/ljar:jar\qvacommon.jar
/ljar:jar\qvautil.jar
/ljar:jar\cryptix32.jar
/ljar:jar\log4j.jar
/JXmx400m
/JDMEM_SIZE=400
/JXrs
BootQVA.class
|
|
with a BootQVA.java 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!
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.
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
java com.you.Main
|
|
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 "com.duck.awt", 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:
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:
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.
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.
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, Test.java, 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.
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.
|