In response to someone at JavaIsDead (Related wiki: ShippingJavaApplications).
The tricky part of making standalone applications in Java is getting the VirtualMachine started (VirtualMachines of course being platform specific). The rest is very easy.
If you are making the assumption that the user has a clue what is going on, you can tell them to type
java package.MyAppfrom the appropriate directory. Of course making this assumption is totally unwarranted, so we'll do it the hard way.
It is very important to remember that regardless of how difficult it is to build a standalone application in Java, it's always easier than building it in C or C++, or any other statically compiled language. These languages need you to compile and package specifically for each and every platform you want to deliver for, and if you don't ship the source code there is no way out for users of other platforms. These include building an InstallShield package for Windows or building an installer shell script for unix. These things can be done for Java as well. The discussions always seems to be about how to deliver a platform independent Java application that can be installed on all platforms as easily as you can install a platform specific application on Windows. That will never happen, but people shouldn't expect that to happen either. Delivering an InstallShield version for Windows, and similarly packaged versions for other OS'es, and shipping a standalone jar file for other platforms is pretty close to the perfect solution to the problem.
First, there are platform dependent scripts. These are what most open source projects are using these days. Generally there will be a Windows .bat, and a *nix .sh (or no extension). I don't know much about the Mac. For fun twists, many people like to throw in .pl's or .js's. A script with any of those extensions can do the basic operations of executing command lines, accessing/changing environment settings, listing directory contents, and printing messages. Most people don't use the last two very much (maybe they don't know how to get directory listings in .bat files). Generally it doesn't take very much.
Then there is of course the fancy approach. The fancy approach is itself divided into more fancy approaches. Here are a few:
Custom Launchers
These are native programs that locate a virtual machine (or install one) and execute it. They can also use JNI if they want to be really fancy.
Java Installers
Programs like InstallAnywhere and many other commercial and free installers support making Java installations. They generally make a native executable to run with a configuration file it reads. Many of them include VirtualMachines, so the user doesn't need one. Some of you (I certainly hope not) may be using NetZero?, as a poor example of a popular Java program.
Privileged Applets
These are actually a type of installer, but I'll separate them anyway. There are many commercial and free installers that support installation of software straight from a web page. These so called one click installers ask the user for permission to take over the computer, and they know what's going on. You'll probably be seeing more of Java Web Start. Web Start is a tool, free and straight from Sun, that allows programs to be installed and started from a web page. It requires the Java Plugin (and, in its current version, its very own Java Plugin) and includes internet updating features.
And of course there is always an easy way. I don't know if this works on *nix (but then *nix people know how to use the command line), but on Windows if you double-click (or single click with the appropriate settings) on a .jar file whose main-class attribute it set, it runs out of the box. I have a feeling that Macs probably support that too. But nobody likes the easy way.
There is something new called JavaWebStart that installs with the virtual machine, and lets you deploy applications over a web browser. The applications do not run in the web browser, though, they run in the JavaWebStart program.