Wrappers Behavior
How does a wrapper extract the jar file?
All the wrappers provided with JExecutable extract it in the default temporary directory. This is the standard behaviour expected by Windows application.
What happens to the extracted jar file when the java application exits?
Whenever possible, the wrappers delete the file on exit. Note however that this is not always possible. For example, an instance of a JVM created using the JVM DLL does not unload cleanly. This behaviour (not to call it a bug) is documented by Sun, and there is no known work-around for it.
Both Windowed and Console wrapper always prefer the JVM instanciation methods that allow them to delete the temp jar after the application exits. Note that embedding a jar in the exe is not required, it is always a safe choice to just leave it on the filesystem near the executable, either in the same directory, or in a sibling or parent directory.
Note also that deleting the files in the windows TEMP directory is not required for Windows applications, and most application just leave them, letting the operating system manage it. The standard behaviour of MS Windows is to propose the user to delete the temporary files when the disks are running low on available space.
JExecutable allows only one embedded jar in the executable binary. Does it mean that all the java application must be entirely contained in this jar?
No. While the JExecutable wrappers may use a jar to bootstrap the java application, you can reference other jar files in a JExecutable project. Those jar files will be accessible to your executable binary, provided the path specified is found at runtime.
It is often convenient to put the main jar in the executable, but you can just put a small jar which purpose is just to bootstrap the application (for instance by displaying a splash screen with specific information and calling the real main class).
How can I run the ant task or the command line in headless mode (so that it can run on unix servers without X-Window)?
The command line always starts in headless mode. For the ant task, you must configure the java environment running ant to run in headless mode. You have to setup the following property:
java.awt.headless=true
How do I pass JVM-specific arguments with the wrappers?
There is no much point in passing JVM-specific arguments for wrappers that are supposed to use any available JVM on the end-user's computer. However, JExecutable wrappers can use JExecutable-specific arguments passed on the command line (for command-line programs) or passed within a short-cut (for window-based programs).
The following arguments all start with a -J and are recognized the JExecutable wrappers (note the case-sensitiveness):
-Jminversion=xxx: Alter the minimum version of the JVM required by the application. This is handy to test the behaviour of the wrapper when no suitable JVM is found. Values are of the form 1.4.2 or just 1.3 (for instance).
-Jmaxversion=xxx: Alter the maximum version of the JVM required by the application. Values are of the form 1.4.2 or just 1.3 (for instance).
-Jmainclassname=fqdn.classname: Specify a classname that should be used by the wrapper as the main class for the application.
-Jcurrentdir=DIR: Specifies the current dir that the wrapper must set up for the application.
-Jmaxheap=SIZE: The maximum heap size that the VM can allocate. The size can be specified in bytes, in kilobytes (suffix k), or in megabytes (suffix m). For instance -Jmaxheap=256M (256 MB of heap space can be allocated) or -Jmaxheap=1200k (maximum 1200 kilobytes can be allocated).
-Jinitialheap=SIZE: The initial memory heap size that the VM allocates at startup. The size can be specified in bytes, in kilobytes (suffix k), or in megabytes (suffix m). For instance -Jinitialheap=256M (256 MB of heap space are allocated at startup) or -Jinitialheap=1200k (1200 kilobytes are allocated).
Wrapper-specific options can also be passed in order to override the defaults parameters set up at wrapper creation. Those options start with -Jskel_ (names are case-sensitive as well).
-JskelDebug=0|1: Specifies whether the wrapper shall start in debug mode or not. In debug mode, it outputs logs in a console (in the standard output for console applications, or in a shell console otherwise). This is usually useful to debug why a wrapper couldn't launch a VM. 0 to disable the debug mode, 1 to enable it.
-Jskel_Message=aString: The message to display to the user when no JVM is found. This is a short sentence that proposes the user to go on downloading a JRE (or going to an URL, depending on the wrapper), or just cancel the action.
-Jskel_URL=http://myurl/wherever: For the Windowed wrapper only, this is the URL where the user is redirected if no JRE is found and if they accept the action.
-Jskel_DownloadURL=http://myurl/wherever: For the Autodownload and Custom Web Download wrappers only, this is the download URL that the wrapper has to download in order to install a JRE.
I have a filetype associated to my program. However, when I launch a document, my application can't find its resources, because the current directory is the directory of the document. How do I fix that?
You can force the wrappers to always force the current directory of your application to be the executable's instead of the document's by enabling the "Sets the executable folder as current directory of the application" option (located in the executable settings panel).
This works correctly because Windows always provides the document as an absolute path argument of the application.
How do I convert my java application into a Windows service?
There is nothing much to do to make a service from a java application. Just select the "Windows Service" wrapper, and build your executable as you would do for a standard application.
The behaviour of the service wrapper is very simple:
First, you have to register the service in the Windows environement. Just run your-app.exe install. Once this is done, you can see the service added to the list of services available on the computer (look for a Services program in the Administration tools of Windows).
Then you can start or stop your service, by calling the executable with the "start" or "stop" arguments (only the first argument of the command line is taken into account). If the "autostart" option is enabled, the service will be automatically when Windows is started.
To uninstall the service, simply run the executable as your-app.exe uninstall, that's all.
The JVM is started and your application launched when the the service starts. The JVM is stopped when the services stops (obviously). Note however that you can exit cleanly, as System.exit(0) is called by the wrapper right before exiting: just add a shutdown hook (Runtime.addShutdownHook()) and you're safe.
Trouble & issues with wrappers
The wrapped applications complain about a "MSVCRT.DLL not found" on Windows 95?
The MSVCRT.DLL file is required by the wrapped application but may be missing on some early Windows 95 computers that have never been upgraded. This file is often installed by third-party application, but it may happen that your users do not have it installed.
To solve this issue, either ask your user to upgrade to a decent OS, or just bundle this MSVCRT.DLL along with your application.
Something goes wrong at launch-time, and the wrapper won't start my java application. How can I investigate?
The first thing to do, is to run the wrapper with the additional argument -JskelDebug=1 (the option is case-sensitive). This will start the wrapper in debug mode, displaying a console (or using the current one, for the console wrapper), and output many useful information.
License
The JExecutable generator is distributed under the terms of the GNU General Public Licence. Please read the License.txt file that comes with the package. Alternatively, you can find additional information on the GNU GPL license on the GNU Web Site
The generated executables are distributed under the terms of the GNU Library General Public Licence and as such do not constrain the licence of the Jar it may embed.
|
