Sponsored Link •
.is that they either try to do too much (but end up doing very little of what you actually want), or theyre so miniscule there isn't one.
If you take a look at the state of play in general installer products, you find they are the one last bastion of the take care of everything so you just have to click it mentality that survives outside of Microsoft. Im not saying that taking care of things in order to support the smooth installation of a product for your users is always a bad thing, just that sometimes it misses the mark.
The big problem with recent installer systems is that they were traditionally founded on Windows platforms, where nearly everything was a known factor the registry, environment variables, etc, etc. So if you wanted to install a COM component, you used regsvr32 or whatever your chosen dose of binary hell happened to be at the time. And all though everybody eventually crosses the line and begins to despise the registry, whether you know it or not (Does Add/Remove programs, showing applications you uninstalled three months ago, sound familiar?), the point is that the registry was a known point of intersection between the end system and the product developers Windows developers just know you have a registry. Spooky how they know that isnt it? In fact the concept of the Registry was so great (the reality of registering 1000s of components and DLLs wasnt so great, though) that Microsoft decided to use the concept again for the .NET GAC (Global Assembly Cache, in this context, kind of similar to the HKEY_CLASSES with versioning)
With Java, the general concepts and ideas used in installers have replicated from the Microsoft world. However, you cant take anything for granted. The biggest being the operating system itself, and then theres the file systems, etc, etc. Java has nothing like the GAC, sure we have the endorsed directories, but those are the sanctity of things that do special stuff and are not to be messed with by us mere mortals. In fact, the classpath allows us to specify any jar or directory for use with our programs. Which is good because we can have different versions of the same library in different files or directories, and we only have to specify what we need; the difficulty comes from that we have to know what we need. And this brings me back to my point about installers.
Either we put all the stuff that our applications depend upon into the installer and let it do its thing, however we run the risk, especially in the open-source enabled, internet savvy world we live in today, that we make our installations bloated and that people will already have the files that we bundle anyway, or that the installation systems we use to build the installers dont actually provide the low-level configuration we need; or we provide intricate step-by-step instructions about where to download files and how to change batch scripts that we think people can follow, but if they're not developers themselves, they nearly always get mixed up.
So either we make things too simple for people, but find we have to make compromises because of the installer architecture, or we think the user to be a programmer like us and assume too much of them.
Ive messed around with installers, and as much as I would really love to put nice little installation pages that allow me to nicely enforce my restrictive license scheme that I myself thought up, that only allows you to run my product if you happen to be called Zebedee and your trial will only work for the twenty days following St. Swithins day, (not the twenty nights following St. Swithins day, I hasten to add), I just dont feel its really what end-users want.
To me theres five degrees of separation between the developer and the end-user, and at each stage the developer knows less and less about the target platform, and some mechanism has to take the responsibility instead.
|Calum Shaw-Mackay is an architect on Java and Jini systems, working in the UK. His interests lie in distributed computing, adaptability, and abstraction. Calum has been using Jini for longer than he would care to mention. His main area for taking the blame (some people would call it 'expertise') is systems integration and distributed frameworks, and is an advocate of using Jini's unique strengths to build adaptable enterprise systems. His opinions are his own. He's tried to get other people to take his opinions off him, but they just won't.|