Not too clear on the libraries available at run time

[Ramon F Herrera]

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.

My Java programs work beautifully when I start them from inside
JBuilder, NetBeans or Eclipse.

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?

My current application is based on OpenOffice. There are 4
indispensable files:

- juh.jar
- jurt.jar
- ridl.jar
- unoil.jar

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:

C:\Program Files\Java\jre1.6.0_03\lib\ext

Because I have a vague recollection (no book, no tutorial mentions
this) that such place is special.

I double click and... it doesn't work.

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.

This simple fact that I am describing here must have turned a whole
lot of people away from Java...

-Ramon

 

[Arne Vajhøj]

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.

My Java programs work beautifully when I start them from inside
JBuilder, NetBeans or Eclipse.

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?

My current application is based on OpenOffice. There are 4
indispensable files:

- juh.jar
- jurt.jar
- ridl.jar
- unoil.jar

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:

C:\Program Files\Java\jre1.6.0_03\lib\ext

Because I have a vague recollection (no book, no tutorial mentions
this) that such place is special.

I double click and... it doesn't work.

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.

This simple fact that I am describing here must have turned a whole
lot of people away from Java...

You put a Class-Path directive in the manifest of your jar file
that points to the other jar files.

It is documented.

If you want to add them system wide, then lib/ext is the place, but
not many Java apps want to use that method. Poor isolation between
apps's different versions of the same libs.

Arne

 

[Mark Thornton]

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.

My Java programs work beautifully when I start them from inside
JBuilder, NetBeans or Eclipse.

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?

My current application is based on OpenOffice. There are 4
indispensable files:

- juh.jar
- jurt.jar
- ridl.jar
- unoil.jar

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:

C:\Program Files\Java\jre1.6.0_03\lib\ext

Because I have a vague recollection (no book, no tutorial mentions
this) that such place is special.

I double click and... it doesn't work.

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.

This simple fact that I am describing here must have turned a whole
lot of people away from Java...

-Ramon

One alternative is to use WebStart. Find somewhere to host the files and
then just send your friends a link.

Mark Thornton

 

[Wayne]

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.

My Java programs work beautifully when I start them from inside
JBuilder, NetBeans or Eclipse.

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?

My current application is based on OpenOffice. There are 4
indispensable files:

- juh.jar
- jurt.jar
- ridl.jar
- unoil.jar

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:

C:\Program Files\Java\jre1.6.0_03\lib\ext

Because I have a vague recollection (no book, no tutorial mentions
this) that such place is special.

I double click and... it doesn't work.

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.

This simple fact that I am describing here must have turned a whole
lot of people away from Java...

-Ramon

"java.ext.dirs" is a list of directories that specifies the locations
in which to search for extensions. By default two standard directories
are listed. The first is the "jre/lib/ext" directory of the currently
used JRE, and the second is a directory (a system-wide repository)
outside of the JRE. This system-wide location allows extension JAR
files to be installed once and used by all JREs installed on that
system. The location varies depending on OS:
Solaris: /usr/jdk/packages/lib/ext
Linux: /usr/java/packages/lib/ext
Windows: %SystemRoot%\Sun\Java\lib\ext (=C:\Windows\...)

Copying jars into an ext directory is dangerous since updates to the
source of the jars (OpenOffice in your case) won't automatically
get copied. Using the per-JRE method at least makes you look at
your jars again whenever the JRE is updated. (Of course, automatic
updates are a "gotcha" in this case; your app one day just stops
working!)

Another danger is, by default installed packages in the system-wide
repository are trusted (i.e. granted the same privileges as if they
were core platform classes in rt.jar). It may be safer to create
your own system-wide repository, and remember to list it each time.

The best idea is to list the extra classes needed in your manifest
file of your jar. These are called "optional classes" for some
reason. See
http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html
for details.

Applets are another matter. You must put the optional jars at the same
code base as the application and they get automatically downloaded.

-Wayne

 

[Ramon F Herrera]

"java.ext.dirs" is a list of directories that specifies the locations
in which to search for extensions. By default two standard directories
are listed. The first is the "jre/lib/ext" directory of the currently
used JRE, and the second is a directory (a system-wide repository)
outside of the JRE. This system-wide location allows extension JAR
files to be installed once and used by all JREs installed on that
system. The location varies depending on OS:
Solaris: /usr/jdk/packages/lib/ext
Linux: /usr/java/packages/lib/ext
Windows: %SystemRoot%\Sun\Java\lib\ext (=C:\Windows\...)

In my WinXP only this directory exists:

C:\WINDOWS\Sun\Java\Deployment

and it is empty.

So, am I supposed to create lib\ and lib\ext ?

Like I said, only God knows how many people have been turned away by
such lack of libraries at run time. Is that what they call vaporware??

-Ramon

 

[Owen Jacobson]

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
post.

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
foo-1.2/
foo-1.2/myapp.jar
foo-1.2/lib/
foo-1.2/lib/dependency1.jar
foo-1.2/lib/dependency2.jar

(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
indispensable files:

- juh.jar
- jurt.jar
- ridl.jar
- unoil.jar

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:

C:\Program Files\Java\jre1.6.0_03\lib\ext

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.

-o

 

[Ramon F Herrera]

You put a Class-Path directive in the manifest of your jar file
that points to the other jar files.

It is documented.

If you want to add them system wide, then lib/ext is the place, but
not many Java apps want to use that method. Poor isolation between
apps's different versions of the same libs.

Arne

This is what I did, Arne:

Eclipse generated an executable jar for me. I changed the extension
*.jar to *.zip, then decompressed it and added this line to the
manifest:

Class-Path: lib/juh.jar lib/jurt.jar lib/ridl.jar lib/unoil.jar

I zipped the folder, and renamed it back to *.jar.

When I double click, it says that the jar file is defective.

-Ramon

 

[Owen Jacobson]

This is what I did, Arne:

Eclipse generated an executable jar for me. I changed the extension
*.jar to *.zip, then decompressed it and added this line to the
manifest:

Class-Path: lib/juh.jar lib/jurt.jar lib/ridl.jar lib/unoil.jar

I zipped the folder, and renamed it back to *.jar.

When I double click, it says that the jar file is defective.

-Ramon

Most zip tools are incapable of generating a valid JAR file[0]. Use
the command-line 'jar' tool instead:

To expand a JAR file:
jar xf foo.jar

To compress a directory tree into a JAR file:
jar cmf foo.jar MANIFEST-FILENAME path/to/root
or without a manifest:
jar cf foo.jar path/to/root

-o

[0] The JAR file spec imposes a few brain-damaged restrictions on the
file's physical layout, which ZIP tools are unaware of. While every
JAR is a valid ZIP, not every ZIP is a valid JAR.

 

[Arne Vajhøj]

Eclipse generated an executable jar for me. I changed the extension
*.jar to *.zip, then decompressed it and added this line to the
manifest:

Class-Path: lib/juh.jar lib/jurt.jar lib/ridl.jar lib/unoil.jar

I zipped the folder, and renamed it back to *.jar.

When I double click, it says that the jar file is defective.

Create a text file in the project in Eclipse write the line
to that and when you generate the jar file tell Eclipse to use
that file as manifest.

Arne

 

[Wayne]

In my WinXP only this directory exists:

C:\WINDOWS\Sun\Java\Deployment

and it is empty.

So, am I supposed to create lib\ and lib\ext ?

Like I said, only God knows how many people have been turned away by
such lack of libraries at run time. Is that what they call vaporware??

-Ramon

Yep, those directories don't get created by default, at least on
Windows. By default jars placed there are "trusted", so that directory
should only be writable by the admin user.

-Wayne

 

[Lew]

In my WinXP only this directory exists:

C:\WINDOWS\Sun\Java\Deployment

and it is empty.

So, am I supposed to create lib\ and lib\ext ?

No, you should do what Wayne suggested.

The usual solution

- for applications is to distribute needed JARs with your application and
refer to them in the manifest of your own JAR.

- for applets is to mount the needed JARs in the same codebase whence comes
your own JAR.

- for Java WebStart apps is to use the JNLP file to specify where the needed
JARs are.

- for web apps is to mount the needed JARs in the
<applicationContext>/WEB-INF/lib/ directory.

Don't mess around with extensions directories.

 

[Wayne]

Roedy Green has an extremely good explanation of class path issues:

<http://www.mindprod.com/jgloss/classpath.html>

I agree with that. But it is missing one important gotcha:

"To run JUnit tests, you'll need the following elements in CLASSPATH:
* JUnit class files
* Your class files, including your JUnit test classes
* Libraries your class files depend on"

JUnit requires use of CLASSPATH. It doesn't understand extension
directories or other classloading methods.

And don't forget that *all* of this discussion only applies when
using the standard classloader.

-Wayne

 

[Arne Vajhøj]

I agree with that. But it is missing one important gotcha:

"To run JUnit tests, you'll need the following elements in CLASSPATH:
* JUnit class files
* Your class files, including your JUnit test classes
* Libraries your class files depend on"

JUnit requires use of CLASSPATH. It doesn't understand extension
directories or other classloading methods.

And don't forget that *all* of this discussion only applies when
using the standard classloader.

What ??

I have been running all kinds of JUnit tests over the years
(primarily via ant scripts) and never put any of that in
CLASSPATH. Normal classpath seems to work fine !

Arne

 

[Arne Vajhøj]

Like I said, only God knows how many people have been turned away by
such lack of libraries at run time.

Java is not that difficult to learn. But it is necessary to
do an effort to learn it. Like reading Sun's tutorial or
a book with similar content.

Arne

 

[Roedy Green]

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.

that is an operating system problem, and one that can be fixed, at
least in Windows. You must set up the association. See
http://mindprod.com/jgloss/jar.html

 

[Philipp]

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.

My Java programs work beautifully when I start them from inside
JBuilder, NetBeans or Eclipse.

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?

My current application is based on OpenOffice. There are 4
indispensable files:

- juh.jar
- jurt.jar
- ridl.jar
- unoil.jar

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:

C:\Program Files\Java\jre1.6.0_03\lib\ext

Because I have a vague recollection (no book, no tutorial mentions
this) that such place is special.

I double click and... it doesn't work.

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.

This simple fact that I am describing here must have turned a whole
lot of people away from Java...

You can (although not trivially) package all your libs with your app in
one unique jar file. This is best done with the FatJar plugin if you use
Eclipse.

Also have a look at OneJAR:
http://one-jar.sourceforge.net/

Phil

 

[pkriens]

I have written a Jar utility for the OSGi framework that is also handy
in your case. You can easily merge all your dependencies in a single
jar. Just create a bnd file (normal properties file):

-output: myjar.jar
-classpath: src, juh.jar, jurt.jar, ridl.jar, unoil.jar
Export-Package: *
Main-Class: com.acme.MyMain

This way you only have to ship a single jar file.

This will also make it an OSGi bundle but the extra headers can't
harm. Bndis described at http://www.aQute.biz/Code/Bnd (and also in
Chinese Code/BndCn!)

Kind regards,

 

[George Neuner]

Eclipse generated an executable jar for me. I changed the extension
*.jar to *.zip, then decompressed it and added this line to the
manifest:

Class-Path: lib/juh.jar lib/jurt.jar lib/ridl.jar lib/unoil.jar

I zipped the folder, and renamed it back to *.jar.

When I double click, it says that the jar file is defective.

Don't unzip the whole thing, just extract the manifest from the .zip
file. Edit the manifest (with a unicode editor) and then update the
..zip file and rename it to .jar again.

I've done this lots of times with no problems.

George

 

[Ramon F Herrera]

Don't unzip the whole thing, just extract the manifest from the .zip
file. Edit the manifest (with a unicode editor) and then update the
.zip file and rename it to .jar again.

I've done this lots of times with no problems.

George

How do I update the .zip file without decompressing it? I am using the
Windows-provided "send to compressed (zipped) folder".

Anyway, I discovered what the problem was. I was creating one folder
too many. If you select a folder and perform a 'send to zipped folder'
an extra layer is added. What I do now it to select the contents of
the folder only, not the "envelope".

Thanks,

-Ramon

 

[Andrew Thompson]

...
How do I update the .zip ..

The later Java runtimes will not check .zip files for code
signatures. It is more reliable to use the .jar extension
consistently.

.. file without decompressing it? ..

..I am using the Windows-provided ...

That is bound to lead to grief. If not now, then at
some point in the future. When dealing with Java
builds, it is best to stick to core SDK tools, and
Ant (which mostly invokes SDK tools).

Also, manifest files are much more reliable when
written by Ant. See the thread in which I posted this
reply, for further details..
<http://groups.google.com/group/comp.lang.java.programmer/msg/a533efe8fb0519d3
--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1