The CurrCon Java Applet displays prices on this
web page converted with today’s exchange rates into your local international currency,
e.g. Euros, US dollars, Canadian dollars, British Pounds, Indian Rupees…
CurrCon requires an up-to-date browser
and Java version 1.7 or later, preferably 1.8.0_20.
If you can’t see the prices in your local currency,
Troubleshoot. Use Chrome for best results.
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,
’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.
Here are some options. I have listed them with the ones I consider most
desirable near the bottom.
Presume the user is as familiar with Java as you. Just provide the
and/or *.jar files and leave it to her to
figure it out.
Manual install. Give the user instructions on unzipping. Tell the
user to type java -jar xxxx.jar
Provide *.bat files or the script
equivalent for the platform.
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
Write tiny kickers,
native executables that know where the corresponding jar is, and the
command line it needs.
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.
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.
Use Java Web Start.
This has the added advantage of automatically applying updates. I
JWS (Java Web Start)
to distribute the Replicator,
which I have kludged to install by
CD (Compact Disk)
The Ideal Installer
Here are my rules for writing a good install program:
The prime requirement is the install bundle should not include
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.
, if you use the hideous EMBED/OBJECT tags, will semi-automatically
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
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.
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
installer which cannot even tolerate installing a 1.3
after you have installed a 1.5.
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.
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.
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
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.
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 Disks)
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
where they can’t get lost. They have to remove the
to read them. Don’t abort the entire install if the next
read after keying fails because the
is not yet up to speed or because the user forgot to re-insert it.
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.
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
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.
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
Installs should not require rebooting the machine, especially not
more than once, even for system software.
The install should display a conservative countdown timer of how
much longer this is going take.
Upgrade installs should carefully preserve existing preferences,
configurations, plug-ins, hotlists, scripts etc. converting to new
formats if necessary.
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.
It should install or upgrade the Java
, getting the latest binaries from the Oracle site as needed.
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.
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.
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.
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.
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
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
Some products install a
and don’t register it along with the other
. This means the other Java apps don’t see it. It also means to
uninstall it, you must uninstall your entire app. The user cannot
separately. That is referred to as a private
The disadvantage is you get all manner of duplicate
. The advantage is the app sticks with the
that brung it.
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.
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
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.
by ej-technologies is a well-regarded installer.
Handles Windows, MacOS, Linux, Unix
Can digitally sign files if you have the necessary code-signing
Dozens of variants. No prices given. You must buy through
resellers. You must ask for a quotation, as if you were buying a
Rolls. Looks very complicated. Supports VMs. Originally
More To Come
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
Roll Your Own
Think what an installer does.
It needs a starter, written as a native exe for the target
It has to ask the user which drive/dir to install on.
It may have to download and install Java.
It has to download files and put them in special spots on the
It has to set up a desktop icon and a menu item.
It may have to build some registry entries.
The way this is typically handled is to invent some hairbrained
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.
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.