When building a client side Java application, with whatever GUI Framework happens to be your favourite one (AWT, Swing, SWT – just to name the obvious triplet), at some point you really have got to ask yourself what would be the best way to distribute your app, without causing the end-user too much pain.
I think that most people would agree that customer acceptance depends to a large extent on the first impression of the user with the particular product. The first contact with your software however, typically is the installation procedure. With java software and the advent of so called “Platform independent” solutions various attempts to address installation facilities have been tried, but just too often, java coders tend to neglect this duty shamefully. Pretty often you find yourself with some classes and jar files you need to copy all over your system, add extensions to your classpath and finally launch the app from the command line via :java classname just to watch it fail a dozen times before you discover that you forgot to add the -Djava.library.path property to the command line (as stated in the readme.txt at line 1846).
The Installer
Windows users can be very choosey about standardized installation procedures, thus I would recommend using a native Windows Installer like the Nullsoft Install System to create an installer (i.e. a Setup.exe) for your application that can be installed and uninstalled properly in a standard, Windows waytm. NSIS offers a pretty cool, powerful macro language for installers that you fortunately don’t really have to learn to create your typical basic installer. For the average installer it is sufficient to use the really cool wizard option of the magnificent open source Installer editor HM NIS Edit by Hector Mauricio Rodriguez Segura and just take your setup.exe and go. You can easily build really complex installers with custom controls with this tool as well – sky’s the limit.
Launching the app
Launching your java application is the next experience the user comes in contact with. If you choose to launch your application through some batch files or worse, let the user start the app through command line as mentioned above, you will most definitely burn in coder hell – and rightly so. There are quite a number of really useful java launchers out there that make launching a java app no less pain than a double click, though the application may actually have serious amounts of dependencies. My favourite one is the Marner Java Launcher by Jacob Marner. It is basically a small executable program written in C, that launches your java VM with all your previously configured options.
Let’s assume following example: You wrote a small app that uses a couple of java libraries and utilises the Eclipse SWT framework for the GUI. Now you want the java launcher to do all your bidding. Your first step should be to create a folder at the root of your project directory called libraries and copy jface.jar, swt.jar and whatever libraries you desire into it. Also, you should copy the native SWT dlls into a separate folder called native. In our case this would be swt-awt-win32-xxxx.dll and swt-win32-xxxx.dll from the eclipse directory eclipse\plugins\org.eclipse.swt.win32_x.x.x\os\win32?. Now we have gathered our source code, the dependent libraries and the native components in one directory.
Now we should create a jar file from our source code that contains a file in the root directory called manifest.mf file. The manifest.mf file contains information which Class should be launched as an entry point into our application (i.e. which class contains the main() method. Also it adds our dependent libraries from the libraries folder to our classpath. The manifest.mf file should look like this:
Manifest-Version: 1.0
Main-Class: de.keyboardsamurais.ApplicationMain
Class-Path: ./libraries/xmlrpc-1.2-b1.jar ./libraries/jface.jar ./libraries/log4j-1.2.8.jar ./lib/swt.jar
Eclipse Users can use the “Export” feature for the jar packaging. Now we are able to call our class from the command line via the call java -jar application.jar. Well…almost! Our application still lacks the native DLL components, so we need to tell the VM where they can be found via a -D flag. We can enter java -Djava.library.path=./native/ -jar application.jar and our app should run flawlessly.
Now, that’s the point where we configure the launcher.cfg file from our java launcher. For our example this config file would look like that:
.
javaw.exe
-Djava.library.path=./native/ -jar application.jar
If you do need an output window for log messages you can exchange javaw.exe for java.exe. You can now click on the Launcher.exe (which you should have copied into your project directory by now) and your application will run like a charm.
You can now wrap it all up into a nice installer and everybody will have a pleasant experience with your software deployment. You might want to change the icon of your launcher.exe to something more fitting. I recommend doing this with Resource Hacker by Angus Johnson.
Last words
Be aware that there are more than a few other options to do all of the above mentioned steps. One of the most promising install systems is Java WebStart and there are a couple of multi platform installers that promise “Write once, run anywhere”. However I am quite happy with the above solution.
Powered by FireStats