views:

3397

answers:

16

Java is one of my programming languages of choice. I always run into the problem though of distributing my application to end-users.

Giving a user a JAR is not always as user friendly as I would like and using Java WebStart requires that I maintain a web server.

What's the best way to distribute a Java application? What if the Java application needs to install artifacts to the user's computer? Are there any good Java installation/packaging systems out there?

+1  A: 

For simple Java apps I like to use Jar's. It is very simple to distribute one file that a user can just click on (Windows), or

java -jar jarname.jar

IMHO, jar is the way to go when simplicity is a main requirement.

jjnguy
+2  A: 

executable files are best but they are platform limited i.e. use gcj : http://gcc.gnu.org/java/ for linux to produce executables and use launch4j : http://launch4j.sourceforge.net/ to produce windows executables. To package on linux you can use any rpm or deb packager. For win32 try http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System

zurk
A: 

The best answer depends on the platform. For deployment on Windows, I have had good results using a combination of one-jar and launch4j. It did take a little while to set up my build environment properly (ant scripts, mostly) but now it's fairly painless.

qualidafial
+5  A: 

If it's a real GUI-having end user application you should ignore the lanaguage in which you wrote the program (Java) and use a native installer for each of your chosen platforms. Mac folks want a .dmg and on windows a .msi or a .exe installer is the way to go. On Windows I prefer NSIS from NullSoft only because it's less objectionable than InstallShield or InstallAnywhere. On OSX you can count on the JVM already being there. On Windows you'll need to check and install it for them if necessary. Linux people won't run Java GUI applications, and the few that will, know what to do with an executable .jar.

Ry4an
A: 

Well from my point of view the superior distribution mechanism is to use something like ClickOnce, or WebStart technology. You just deploy the version to the server and it gets automatically to the clients when the version is released. Also the Eclipse RCP platform contains UpdateManager that does what WebStart do, but also much more.

Since I am using Maven2 for building, the deployment is just a piece of cake: copy the built jar to the location on the server, update the jnlp file if needed and you are done.

Petr Macek
+2  A: 

advanced installer makes it easy to package java apps as windows executables, and it's quite flexible in the way you can set it up. I've found that for distributing java applications to windows clients, this is the easiest way to go.

rustyshelf
+18  A: 

There are a variety of solutions, depending on your distribution requirements.

  1. Just use a jar. This assumes that the user has the the correct java version installed, otherwise the user will get "class-file format version" exceptions. This is fine for internal distribution inside a company.

  2. Use launch4j and an installer like NSIS. This gives you a lot more control, although the user can still do stupid stuff like un-installing the java runtime. This is probably the most popular approach, and what I currently use.

  3. Use Webstart. This also assumes that the user has the correct java version installed, but it's a lot easier to get going. My experience is that this is fine for tightly controlled intranet environments, but becomes a pain with larger deployments because it has some many weird failures. It may get better with the new plug-in technology in Java 1.7.

  4. Use a native-code compiler like Excelsior JET and distribute as a executable, or wrap it up in an installer. Expensive, and it generally ties you to a slightly older version of java, and there is some pain with dynamic class-loading, but its very effective for large-scale deployment where you need to minimise your support hassles.

Noel Grandin
Just a note on Webstart: As long as the user has a version of Java installed that's not from the stone age (e. g. 1.2) webstart can be told to download and install a newer Java version of the one you require for your program is not there yet. Look at the .jnlp file syntax. Of course it still quite prominently displays that you are using Java which might be inappropriate depending on the clients you deal with. In those cases you should indeed some sort of "native" installer/file format and hide the implementation details as far as possible.
Daniel Schneller
I don't like Webstart. It has too much Java/Sun branding. It's hard to get it to work right. Setting up the code signing is more trouble than it's worth and the user doesn't understand the security benefits and messages anyway. If you want to do anything on the users system you're going to have to pay for your code signing certificate to get rid of the scary warnings It does a lot of complicated caching which can cause problems. Maybe OSGi or upcoming Java modules will offer similar auto update benefits. I use a variation of #2 and create DMG/Packager for mac all from Ant.
Cal
@Noel. I used NSIS as you suggested. I also looked at launch4j. Why do you recommend using both?
JackN
A: 

I develop eclipse RCP applications. Normally to start an eclipse application an executable launcher is included. I include the java virtual machine inside the application folder in a /jre sub directory to ensure that the right java version will be used.

Then we package with Inno Setup for installation on the user's machine.

Mario Ortegón
A: 

I would zip the jar file along with other dependent jars, configuration files and documentation along with a run.bat/run.sh. End user should be able unzip it to any location and edit the run.bat if required (It should run without editing in most of the cases). An installer may be useful if you want to create entries in start menu, desktop, system tray etc.

As a user I prefer unzip and run kind of installation (no start menu entries please). However People outside IT industry may have different preferences. So if the application is largely targeted for developers zip-run.bat route and applications for general public may be installed using a installer.

Rejeev Divakaran
+1  A: 

Although I haven't used NSIS (Nullsoft Scriptable Installer System) myself, there are install scripts that will check whether or not the required JRE is installed on the target system.

Many sample scripts are available from the Code Examples and Real World Installers pages, such as:

(Please note that I haven't actually used any of the scripts, so please don't take it as an endorsement.)

coobird
+1  A: 

JSmooth is a simple program that takes your jar and wraps it up in a standard windows executable file. It comes with a simple GUI that allows you to configure the required JVM, bundle it with the application or provide an option to download it if it's not already installed. You can send the exe file as is or zip it with possible dependencies (or let the program download the extra dependencies from the net on startup). It's also free, as in beer and speech, which may (or may not) be a good thing.

stian
A: 

installanywhere is good but expensive one - i have not found (as) good free one

Tom
See this for InstallAnywhere alternatives, including some free ones (as well as commercial ones that are much more reasonably priced): http://stackoverflow.com/questions/759855/what-are-good-installanywhere-replacements-for-installing-a-java-ee-application
Jonik
+2  A: 

I needed a way to package my project and its dependencies into a single jar file.

I found what I needed using the Maven2 Assembly plugin: Maven2 Assembly plugin

This appears to duplicate the functionality of one-jar, but requires no additional configuration to get it going.

David Carlson
+1  A: 

It depends on how sophisticated your target users are. In most cases you want to isolate them from the fact that you are running a Java-based app. Give them with a native installer that does the right thing (create start menu entries, launchers, register with add/remove programs, etc.) and already bundles a Java runtime (so the user does not need to know or care about it). I would like to suggest our cross platform installation tool, BitRock InstallBuilder. Although it is not Java-based, it is commonly used to package Java applications. It can be easily integrated with Ant and you can build Windows installers from Unix/Linux/Mac and the other way around. Because the generated installers are native, they do not require a self-extraction step or a JRE to be already present in the target system, which means smaller installers and saves you some headaches. I also would like to mention we have free licenses for open source projects

Daniel Lopez
A: 

What's the best way to distribute a Java application? What if the Java application needs to install artifacts to the user's computer? Are there any good Java installation/packaging systems out there?

In my experience (from evaluating a number of options), install4j is a good solution. It creates native installers for any platform, and is specifically geared towards installing Java apps. For details, see "Features" on its website.

install4j is a commercial tool, though. Especially if your needs are relatively simple (just distribute an application and install some artifacts), many other good options exist, including free ones (like izPack or the already mentioned Lauch4j). But you asked for the best way, and to my current knowledge install4j is the one, especially for distributing larger or more complicated Java (EE) apps.

Jonik
Do you know how to force it to run JVM 5.0 on the Mac OS? With windows you just bundle the JRE, but on the mac it's possible that they have another default JVM configured. So I'm not sure how to explicitly force it to use the specific JVM version you want...
Stephane Grenier
@Stephane, I haven't actually created OS X installers using install4j, but I think it shouldn't be a problem given the flexible JRE bundling/detection options it has. For more about them, check the links in this answer: http://stackoverflow.com/questions/995881/jar-installer-that-auto-detects-if-java-is-there-and-autostarts-the-application/995943#995943
Jonik
Since Mac supports creating Java app bundles you can just specify the JRE in the info.plist like so...<key>JVMVersion</key><string>1.5+</string>You can remove the plus to require a specific version.This is how I do it but I don't use install4j. There are a bunch of pages explaining creating Mac App budles on the web. I also, recommend just looking at how limewire or vuze (java apps) do it. You can also look at the build scripts they use to build the app bundles and dmg files since they're open source!
Cal