[Jnumerical-general] Installer

[Daniel L. <le...@on...>]

Good day Frank,

Here's the files I promised. Nothing exciting, but it worked for my purposes. 
You can easily build something similar to download libraries as needed from a 
network. Of course, you can do *much* better than I did. What I did was a 
quick and dirty solution, but my client at the time didn't need anything 
better.

Mind you, I tried many high level tricks before going down the low and dirty 
path. They just weren't reliable enough. Mind you, I don't know about very 
recent JVMs, they may have improved (even though I doubt it).

Basically, my understanding is that if you want to avoid troubles, install 
your libraries in /jre/lib/ext. This way, you application will run as a 
(signed) applet, as a webstart application and certainly, it will work well 
with jython.

There is no reliable way (that I know of) to do this automatically. When Sun 
automatically downloads "extensions", it will put them anywhere but in 
/jre/lib/ext. That brings a lot of trouble. Plus, what happens when the 
(wrong) library is in /jre/lib/ext? Well, it gets loaded first, so no luck 
there... you really need jre/lib/ext, no matter how you turn the problem 
around (yes, you can get around that with classloaders, but then, you've got 
security issue whenever you are in a sandbox, plus, custom classloaders are 
dirty, dirty).

Mind you, even by doing it yourself, you've still got a problem: jre/ext might 
not be user writeable!  That's right! It could be that your user can't 
install extensions properly! Clearly, the classpath/jar/classloader paradigm 
is showing its age. No matter how much hacking you do, something *will* 
eventually go wrong.

In theory, for example, you could have more than one jre/lib/ext directory 
(one for each user), but Sun never provided a way to add jre/lib/ext 
directories, so you are out of luck.

Of course, you've got also the problem that extensions have no reliable 
versioning. That means that you may or may not write over an extension needed 
by another application (that happens often with XML parser), you may 
incorrectly assume that the proper extension is in place whereas you've 
really got an older or newer version in place... and so on. So, you would 
need to check this, check that... ah...

Basically, it is very, very dirty. All these things will never get fixed I'm 
afraid. Java is a very nice language... but its hasty beginnings are a major 
drag on it. And any time someone suggest to break away from the old tricks 
and evolve into something better, they typically get hammered so hard that 
nobody dares to speak out loud about Java shortcomings anymore... nobody from 
the Java community, that is.



-- 
Daniel Lemire, Ph.D.
Research Officer, National Research Council of Canada
http://www.ondelette.com/acadia/