Re: Not too clear on the libraries available at run time
On 2007-12-02 10:39:09 -0800, Ramon F Herrera <firstname.lastname@example.org> said:
One of the fundamental problems with Java is that you double click on
an executable jar... and nothing happens. Or perhaps the program does
start but then it stops working, when you click on a button or menu.
Compare with an *.exe file. You double click on it, and it works.
If you've done Windows development, think back to the idea of "DLLs
distributed with your app" and keep that in mind while you read this
When I was a newbie, I made a decision: "let's just put every single
needed library in the jar file". After all, my programs were simple
and small at the time.
In Unix, you just place any ancillary stuff (*.so or *.a) under /usr/
local and a lot of programs work properly. With Java (on Windows, BTW)
where the hell am I supposed to place the third party jar libraries?
Traditionally, in parallel with your application. Your distribution
would be a zip file containing
(Other structures are, of course, equally valid.)
The myapp.jar Class-Path manifest entry would refer to
lib/dependency1.jar lib/dependency2.jar, which is sufficient for the
runtime to locate the classes in those JARs. Manifests are explained
on Sun's site:
My current application is based on OpenOffice. There are 4
This, of course, relies on being permitted to distribute these JAR
files. You'll have to check the OpenOffice license yourself; while I
suspect you can distribute them, I'm not certain of that. If you can't
distribute those JARs, then you're going to have a problem as their
location is going to be different on every system your app runs on;
solving that problem is non-trivial.
Eclipse doesn't seem to like my idea of stuffing those in the final
executable jar. So, let's try placing them in the directory:
Please don't use global extensions. They're visible to every java
program running under the same JRE, and if another program decides it
needs a different version of the same classes then, unpredictably,
either your version or his version will not be loaded. Keep your
dependencies contained to the app that needs them.
The CLASS_PATH environment variable suffers from the same problems.
Roedy Green has an extremely good explanation of class path issues:
I would like to send my application as an attachment to some friends.
All I can guarantee is that they have Java in their Windows PCs. They
will not mess around with their PATH.
As Mark Thornton suggests, your best bet is likely Java Web Start,
which lets you skip the jar Class-Path entries in favour of JWS' own
"libraries" mechanism. This still relies on being allowed to
distribute the JARs yourself, but it makes managing them and launching
the program much easier.