Please note: The following describes an alternative way to package your Java applications with a pre-installed Java Runtime Environment (JRE) to allow for intuitive "unzip & run" installation of your application (mainly targetted at Windows systems and Windows users admittedly).BlackwellIf you think this is a silly idea, you better hurry and tell Oracle about your concerns, as this is exactly how they distribute some of their applications.
1.) Copy the "JRE" directory from your JDK install directory (for example "C:\Program Files\JDK 1.3.1\JRE") to some other location. 2.) Copy your class files and what else you need (JAR files, image files, etc.) into your copy of the JRE directory. Not into one of its subdirectories, but directly into the "JRE" folder. 3.) Get JavaRunner from Current Stuff and copy the "JavaRunner.exe" and "PrimeBase-RDBMS.txt" files into that "JRE" directory as well. 4.) Rename "JavaRunner.exe" to whatever your application exe filename should be (for example "MyGreatApplication.exe"). 5.) Edit "primebase-rdbms.txt" to contain only this on the first line: "bin\javaw MyClass". Depending on what JDK/JRE version you use, you might have to provide the -cp or -classpath parameters to include the current directory in the CLASSPATH (yet another mystery from Sun Microsoystems), so that you would place this in the file: "bin\javaw -cp . MyClass" or "bin\javaw -classpath . MyClass" Remember that you can actually test and debug this command by starting a command prompt/command line, cd'ing to your custom JRE directory and entering the above command you plan to stick into the "primebase-rdbms.txt" file. 6.) Rename the "JRE" directory to what your application's directory should be called. 7.) Zip the complete directory up and ship it to whoever is interested in your application.
This results in a comparatively big file, but hey, MS Office is awfully large too, who cares?Important note: Make sure you offer a download of the raw class files or a JAR package too, so that people with a global JDK or JRE already installed don't have to bother with your big for-nerds distribution of the application. (Also keep the poor fellows without Windows in mind who might like to use your application as well.)
You would want to check wether Sun Microsystems allows this kind of integration with their JRE...But hey, if they don't, probably ignore them - ease of use must have the higher priority clearly.
The positive side effect
Another very desirable side effect of this kind of distribution is not so apparent:
Your application will have its own copy of a Java Runtime Environment.
While this may seem like a waste of harddisk space (afterall many Java applications usually can share a single Java Runtime Environment without too many problems) this ensures that your application is always being run with the JRE that you know your application is compatible with.
Especially in commercial and enterprise environments certain programs are used for years, if not decades. Very often these programs perform very vital tasks in complex systems. The last - really the very last - thing you want to do to such an application is screw with the environment that it requires to work correctly. If the application has its own JRE, there is no need to and the user can have a globally installed JRE for all other Java applications still anyway.
This approach should also work with the Linux version of the JDK/JRE, with the difference that you should make sure to include all necessary shared object files just as well, as Linux distributions differ a lot and may be missing some of the shared object files vital for running the JRE. (Of course you could also write a small "executable" wrapper for Linux, like JavaRunner for Windows, but a simple script file would do the trick just fine, I guess.)