installer : Java Glossary

Introduction

Most programs now a days come with a commercial installation program. These are typically much better than the installs of yesteryear, but they still needlessly annoy and confuse the end users. Installation is the weakest link in Java. Dealing with conflicting JVM (Java Virtual Machine) ’s, conflicting classpaths, conflicting versions of the Applet plug-in mean the average user has little chance of successfully installing and running a Java application. See below for a list of the current installer tools. Before installers can be successful, JVM ’s must stop all use of classpath, autoexec.bat and the SET environment, places where different JVMs (Java Virtual Machines) can collide. Oracle also has to start ensuring that multiple versions of its plug-in do not interfere with each other.

Installer Options

1. Presume the user is as familiar with Java as you. Just provide the *.java, *.class and/or *.jar files and leave it to her to figure it out.
2. Manual install. Give the user instructions on unzipping. Tell the user to type java -jar xxxx.jar
3. Provide *.bat files or the script equivalent for the platform.
4. Use an exe wrapper around the jar.
5. Set up jars to be double clickable, either manually or with a little C or JNI (Java Native Interface) program. See this instructions for making jars double clickable. Tell the user to type xxxx.jar or click a shortcut to a jar. Ideally you install the shortcuts on the desktop and menus for her. Unfortunately this is all very platform dependent.
6. Write tiny kickers, native executables that know where the corresponding jar is and the command line it needs.
7. Distribute AOT (Ahead Of Time) natively compiled and highly optimised executables as if they were traditional C++ programs, perhaps using the installer than comes bundled with JET.
8. Use a third party installer program such as InstallAnywhere. This approach gives you the splashiest first impression and makes your app look like a familiar C++ app. They are still not smart enough to install a JRE (Java Runtime Environment) if a suitable one is not already available. Usually they produce packages that are CD-installable as well perhaps with bundled JREs (Java Runtime Environments) and multi-platform autorun.
9. Use Java Web Start. This has the added advantage of automatically applying updates. I use JWS (Java Web Start) to distribute the Replicator, which I have kludged to install by CD (Compact Disc) as well.

The Ideal Installer

1. The prime requirement is the install bundle should not include runtimes, JVM s, resources, classes etc. that you already have. It should sniff about to find out what is missing and automatically fetch what it needs from original sources. I have yet to see an installer that does this properly. The closest I have encountered in the JetPack which lets you distribute two versions of your JET (Just Enough Time) application, one complete with a 16 MB runtime DLL (Dynamic Link Library), and another to upgrade you from version N to N+1 which contains only the classes and resources that have changed. With JETPack it is still up to the end user to decide which sort of install to attempt. That should not be his problem. JWS , if you use the hideous EMBED/OBJECT tags, will semi-automatically install a JVM for you and will keep jars for an application up to date. If installed a Jardiff server, it even has a way of keeping individual members up to date, not just whole jars. Obviously, for a CD install you can usually afford to throw in the kitchen sink and you have to for off-net installs. A corollary to this, in a sane world a self-extracting installer need not contain the code for extraction, just a laundry ticket to get the code if it is not already present. It is quite ridiculous for every application to deal with its own installation. It should be handled by a fully generic tool.
2. My second major requirement is that an install must be robust. Most installs, if they ever fail, require an expert to put them on the rails again. They should do a sanity check on the existing installation and remove, replace and add files as necessary to put things aright. For half a chance of success, installers should start with the presumption somebody has maliciously tampered with all the files, programs and registry entries. Today’s installers are far too fragile, particularly Oracle’s JVM installer which cannot even tolerate installing a 1.3 JVM after you have installed a 1.5.
3. An install should display a pleasing graphic to start. This gives confidence that the product is of professional quality. However, it is quite unnecessary to have a Star-Wars level animated production to entertain during the setup. There should be no need to even look at the install, except for the first screen on two.
4. The install should ask all its questions up front so you can have a short conversation with it, then walk away or run it in the background. If it needs a blank diskette, it should ask for it up front. If it wants a branding key, it should ask up front, not after 40 minutes.
5. The install should check for free space on local hard disks and display them in descending order. By default, it should select the one with the most free space, not necessarily C:. Selecting the drive should be a separate question from naming the directory.
6. If an install required downloading 10 files, you should select the options up front, then go home and leave the install to automatically download all the files overnight and install them unattended. If the phone connection disconnects, it should restart it automatically and optionally hang up when done.
7. Keyed serial numbers are a dishonest ploy that have no effect on pirates and hurt legitimate users. A pirate can simply enter a known valid serial number. MS does all it can to make sure you will lose your serial numbers or confuse them between many different products, so that when it comes time to re-install, the codes won’t work and then you are forced to buy a new copy of the software. Serial numbers are evil, dishonest and useless. You can have a drawer full of Microsoft CDs (Compact Discs) and a drawer full of holograms/serial numbers and no way of matching the two. If you must use them, consider that users will properly write them on the CDs where they can’t get lost. They have to remove the CD to read them. Don’t abort the entire install if the next CD read after keying fails because the CD is not yet up to speed or because the user forgot to re-insert it.
8. Branding keys, in contrast, are legitimate. To discourage piracy, the user’s name is branded into the software in a way that if it is tampered with, the program will stop working. Ideally, software should come pre-branded, or you should be able to download a branding file when you purchase software that automates the branding process. If at all possible, installs should avoid making users type in long strings of gibberish to effect branding. At worst, they could just have to cut and paste the gibberish strings from some email.
9. Registration branding keys ideally should be purely numeric, broken into groups of 4. Next best are pure alphabetic, case-insensitive, avoiding the letters O, I and L. Spaces should be ignored. Ideally you can paste in the entire serial number in one fell swoop.
10. The install should ask only one question per dialog box. It is too easy for the user to miss one of the questions otherwise, especially the crucial one, which drive to install on.
11. The install should be prepared to run in the background unless it is a system level install. Programmers with immense egos believe that users have nothing better to do that watch their installs copy files. Their installs typically grab the entire screen and insist users watch them to completion, making users hit Enter every 15 seconds just to ensure they savour every little animated burble of ad copy.
12. Installs should not require rebooting the machine, especially not more than once, even for system software.
13. The install should display a conservative countdown timer of how much longer this is going take.
14. Upgrade installs should carefully preserve existing preferences, configurations, plug-ins, hotlists, scripts etc. converting to new formats if necessary.
15. Where it makes sense, upgrades should offer you the choice of preserving the old version. Where it does not make sense, the install should leave a result indistinguishable from a clean install of the new version and not leave junk files and registry entries left behind from the old version. It is extremely common for installs to fail over a previous version or a previously aborted install. Vendors should test the install to make sure it does not choke over any junk left behind by previous attempts.
16. It should install or upgrade the Java JVM , getting the latest binaries from the Oracle site as needed.
17. The uninstall should optionally keep configuration and data files, or remove every last trace of the app from the registry, the disk, menus, the desktop, the autostart etc. They should not only remove files, they should remove directories.
18. I implemented a zero-click install for save.com. It uses a tiny signed Applet that downloads an exe and execs it. The exe is a traditional install program. It asks no questions. It can’t get any simpler than that for an initial install. All you have to do is visit the web page and grant security clearance.
19. If there is a trial period of say 20 days, days on which the user has no time to experiment with the program should not count. For me, the time often expires before I have taken even 10 minutes to experiment and the vendor then blocks me from further experimentation for the rest of my life, hardly the way to make a sale.
20. Java Web Start is the easiest way to implement one-click installs and to ensure automatic updating. Java Web Start is rapidly becoming the way all Java applications are delivered. It is so much more convenient for the end user. It is free. The downloads are tiny. It is very little work to prepare a Web Start app. The only serious drawback is to work properly it needs a non-standard file server to deal with versioning.
21. Check your questions with a variety of people to see if anyone can misinterpret them in an ambiguous way. One I question I saw recently asked in effect Exiting now will have a horrible consequence. Continue? Did they mean continue with the exit or continue running the program without exiting? I often write letters to such authors telling them of the ambiguity. The fools write back telling me which they intended and explain why there is no problem with ambiguity if you look at it the right way.
22. You also have the problem to consider of preventing piracy by licensing your software. You can buy a canned solution like Agilis EasyLicenser or you can roll your own branding with ideas from my project of branding a software rental or the installer project. You might consider use of an obfuscator to make your code harder to reverse engineer. The strongest technique is AOT compilation to machine code. Java class files are too easy to reverse engineer.
23. Have a look ad Adobe’s DreamWeaver installation. Other than the complication of making you pick a temporary location to unpack files, it has a very easy to understand way of selecting the install location.

Private JVM

The disadvantage is you get all manner of duplicate JVMs . The advantage is the app sticks with the JVM that brung it.

Caveats

Avoid the Optimum Installer. It goes out of its way to trick and irritate your customers. I go so far as to call it malware.

Smart Installers

Companies such as Logitech use smart installers. These are particularly good for device drivers, or where there are many variants on the download, e.g. for different languages, different models, OS (Operating System)es, versions, or when the download is huge. You download a tiny universal installer that sniffs about to find out the details it needs about what OS you have, what hardware you have, what drivers you have, then selects just the modules you need and installs them. Some smart installers do additional downloads automatically. If you re-run the installer, it will get the latest versions, unlike a traditional installer that would just reinstall the versions embedded it itself. The disadvantage is a smart installer requires Internet access which may not be present, possibly for security reasons.

Install4J

• Handles Windows, MacOS, Linux, Unix
• Can digitally sign files if you have the necessary code-signing certificates.
• Download and install a JRE on demand.
• Statically bundle a JRE.
• Integrates with ANT (A Neat Tool).
• Can build CD installers.

• Complicated for the simple case.
• for the multiplatform package with IDE (Integrated Development Environment), command line and ANT control. You can buy just-Windows without command-line control for considerably less.

Comparison of Application Installers

If would be great if you would research other installers and send me the raw data by email for inclusion in the table. Don’t worry about formatting.

Roll Your Own

Think what an installer does.

1. It needs a starter, written as a native exe for the target platform.
2. It has to ask the user which drive/dir to install on.
3. It may have to download and install Java.
4. It has to download files and put them in special spots on the disk.
5. It has to set up a desktop icon and a menu item.
6. It may have to build some registry entries.

The way this is typically handled is to invent some harebrained script language, then keep tacking feature after feature onto it. It would be simpler to develop a library. You then use C++ to compose your installer. You are then free to handle any weird need by writing your own code. You just ignore the library code not needed for a particular app. What makes the task difficult is trying to handle multiplatform installs with a single script. It is much easier to think about composing an installer for each platform, factoring out commonality where feasible. Don’t try to create a master distributable that installs anywhere unmodified. The abstraction needed just overamps the human brain.

Another approach is to write a program to compose a program, where you can include your own custom stubs, then compile. This is more difficult and much less flexible, but can allow you to crank out installers more tersely.

Other than the restriction of having to code in C++, no individual piece of this work is particularly complex, especially in an individual case. It only gets complicated when you try to invent an installer for all languages, for all platforms, for all conceivable applications. You try to create installers without the programmer having access to that platform or the build tools for that platform. That makes it much more difficult.

Someone might write a greatly simplified multi/platform installer where users submit source code to a server farm for the various target platforms to be compiled and tested, rather than trying to generate platform-specific code without using native compilers and build tools, i.e. with both hands tied behind your back.

If you are going to roll your own you can run a both Windows and Ubuntu on PC (Personal Computer) partitions. You might find an old slow discarded Mac just to compile your installers.

Summary

I was underwhelmed by all the overpriced commercial installers and decided some day I would eventually have to write my own. However, that project has been on my todo list a very long time. One way to find a good installer is just to install other people’s software and see how the end result looks to the end user. Over a period of a year, you should be able to find some suitable candidates. There are now many more to choose from than when I did my last serious look.