Java - Simplifying Your Deployment

If what we provide to our customer is a software that they run in their own environment, we should look into using an installer that are suitable for their platform / operating system.

If we are writing application for our own internal consumption, and we prefer to use .jar instead of .exe (due to corporate culture or whatever), we can use eclipse to package multiple .jar files into a single executable, but keep in mind that there are some limitation with using executable jar (the destination host may not have the right version of JRE / JDK installed). Depending on the "jar to exe" tool that we use, when our exe application is invoked, it can check to see if appropriate JRE / JDK exist, and if not, it can automatically download and install appropriate JRE / JDK.

Regardless whether we are using an installer or distribute our software as a .exe (or which ever extension is appropriate for the operating system that our customer use), the software is installed on our customer's environment, and we need to have a mechanism to notify the customers of new versions (either manually mass email all our customers when we release new version, or the software should check for new version and inform the customer during its start-up sequence). For minor releases, perhaps we should not mass email our customers, but let our software notify the customer during its startup sequence. If our software checks for new version and notify the customer during its start-up, we should allow our customers to disable this feature. Perhaps, we should have a web interface to allow our customer to set their preference on whether they want to be mass notified of new major version, new minor version, and whether the software should do the notification, or no notification at all. For beta customers, as well as real customers, when they sign up, we automatically set appropriate preference for them, but we inform them about the preference page via email so they can go to the preference page and configure it the way they want. We should also allow them to opt-out.

Perhaps we can do what FileZilla or Notepad++ do: if there is a new version available, the customer can choose to download and install the new version, restart and use the new version immediately.

Java Web Start is also interesting. We should investigate what it can do. Apache Hudson (Jenkins) allows the customer to test drive the product on their local computer (possibly without installing itself permanently, or it may seemlessly install itself).

If our product follow as Saas (hosted service) model, we do not have to worry about communicating to our customers on the technical issues associated with distributing our software, but we are still responsible for communicating the changes (bug fixes, new features, enhancement to existing features, etc). This communication is particularly important if there is significant changes in the UI (depending on our user demographic, they may be so used to the previous user interface, and therefore they may be confused with the new interface). This is particularly true if our customers are busy professionals (doctors, nurses, etc).

Java Web Start
Using Eclipse to package executable jar
Using Eclipse to prepare .exe file

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License