installer : Java Glossary

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 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 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 if a suitable one is not already available. Usually they produce packages that are CD-installable as well perhaps with bundled JREs and multi-platform autorun.
9. Use Java Web Start. This has the added advantage of automatically applying updates. I use JWS (Jawa Web Start) to distribute the Replicator, which I have kludged to install by CD as well.

The Ideal Installer

1. The prime requirement is the install bundle should not include runtimes, JVMs, 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 application, one complete with a 16 MB runtime DLL, 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 Sun’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 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. 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.
17. 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 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.
18. 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.
19. 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.
20. You also have the problem to consider of preventing piracy by licensing your software. You can buy a canned solution like ePatha, 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.
21. Have a look ad Adobe’s DreamWeaver installation. Other than the complication of making pick a temporary location to unpack files, it has a very easy to understand way of selecting the install location.