How to use libraries inside the exported jar

[Etantonio]

Good evening,
I've a java application using several jars, from Eclipse I export it
including the jars with the following manifest file

************************************************************
Manifest-Version: 1.0
Sealed: true
Main-Class: it.imt.edusat.EduSat
Class-Path: jcalendar-1.3.3.jar iText-2.1.3.jar jcommon-1.0.14.jar
jfreechart-1.0.11.jar RXTXcomm.jar log4j-1.2.15.jar
************************************************************


these libraries are inside the exported jar but if I launch it using
the command
java -jar Edusat.jar

these libraries are not founded, to have the program working I must
insert also these libraries inside the same folder where I've the jar.

How I could use the libraries that are inside the jar ??


Thanks,
ANtonio
www.etantonio.it/en

 

[markspace]

How I could use the libraries that are inside the jar ??

The default class loader will not look inside jar files for additional
libraries. It's designed to use libraries as eternal files, so that
they can be managed by a sysop.

OneJar will look inside jar files for libraries. There's even an
Eclipse plug-in for it, I believe.

http://one-jar.sourceforge.net/

 

[Andrew Thompson]

..
How I could use the libraries that are inside the jar ??

Do not put Jars inside Jars, that will not work.

If it has a GUI, launch it using Webstart and add
the references to the extra Jar's inside the JNLP
launch file. The webstart client will do the
rest of downloading them, and adding them to the
run-time classpath of the app.

 

[markspace]

It's designed to use libraries as eternal files....

That should have been "external files." Just trying to be clear for the
international readership here.

 

[Roedy Green]

these libraries are not founded, to have the program working I must
insert also these libraries inside the same folder where I've the jar.

How I could use the libraries that are inside the jar ??

You could put the libraries in the ext directory, see
http://mindprod.com/jgloss/ext.html

You could find out if the library names inside the jar represent names
relative to the main jar or relative to the CWD or relative to
something else. Andrew Thompson probably knows from his experiments.

You could simply post copies of the lib jars next to the main jar.

You could use JWS which gives you finer control of aux jars.
See http://mindprod.com/jgloss/javawebstart.html


--
Roedy Green Canadian Mind Products
http://mindprod.com

If everyone lived the way people do in Vancouver, we would need three more entire planets to support us.
~ Guy Dauncey

 

[Arne Vajhøj]

I've a java application using several jars, from Eclipse I export it
including the jars with the following manifest file

************************************************************
Manifest-Version: 1.0
Sealed: true
Main-Class: it.imt.edusat.EduSat
Class-Path: jcalendar-1.3.3.jar iText-2.1.3.jar jcommon-1.0.14.jar
jfreechart-1.0.11.jar RXTXcomm.jar log4j-1.2.15.jar
************************************************************

these libraries are inside the exported jar but if I launch it using
the command
java -jar Edusat.jar

these libraries are not founded, to have the program working I must
insert also these libraries inside the same folder where I've the jar.

How I could use the libraries that are inside the jar ??

Put them outside the jar instead.

Arne

 

[Arne Vajhøj]

You could put the libraries in the ext directory, see
http://mindprod.com/jgloss/ext.html

Never do that unless there are very specific classloader
reasons to do that.

It is the equivalent of copying application DLL files
to c:\WINDOWS\system32 !

Arne

 

[markspace]

You could put the libraries in the ext directory, see

Gotta agree with Arne, this is a terrible idea. Don't do this.


Does anyone know when putting things in the ext directory is a good
idea? I can't think of any. Has Sun ever released an extension to
existing JVMs that properly belonged in the ext directory? Something
like that would be the only thing I could think of that should go there
-- actual vendor extensions to the JVM.

 

[Arne Vajhøj]

Gotta agree with Arne, this is a terrible idea. Don't do this.

Does anyone know when putting things in the ext directory is a good
idea? I can't think of any. Has Sun ever released an extension to
existing JVMs that properly belonged in the ext directory? Something
like that would be the only thing I could think of that should go there
-- actual vendor extensions to the JVM.

They get loaded by a class loader higher up.

But I can not think of any situation where it is relevant.

The endorsed directory has its use !

Arne

 

[Roedy Green]

Does anyone know when putting things in the ext directory is a good
idea? I can't think of any.

It is easy. It works. It requires no code.

I think you are exaggerating the dangers of exposing a jar to a an app
that does not need it. I have never run into trouble with that. You
have fully package/class qualification to keep things sorted out.

For corporations, what you say may be true, but not for an individual.
--
Roedy Green Canadian Mind Products
http://mindprod.com

If everyone lived the way people do in Vancouver, we would need three more entire planets to support us.
~ Guy Dauncey

 

[markspace]

For corporations, what you say may be true, but not for an individual.

How do you know Etantonia is targeting individuals and not corporations?


I think you make a fair point but no one asked the OP's environment
before posting replies. I actually assumed it was a corporate
environment, and he needed a zero-config install.

 

[Arne Vajhøj]

It is easy. It works. It requires no code.

The alternatives does not require code either.

I think you are exaggerating the dangers of exposing a jar to a an app
that does not need it. I have never run into trouble with that. You
have fully package/class qualification to keep things sorted out.

That does not help if it is two different versions of the same
software.

Besides it is only 1 out 3 problems with this approach.

The other two are:
* problems when Java is upgraded and the stuff not copied over
* difficulties seeing what a given code depends on

Arne

 

[John B. Matthews]

It is easy. It works. It requires no code.

I think you are exaggerating the dangers of exposing a jar to a an
app that does not need it. I have never run into trouble with that.
You have fully package/class qualification to keep things sorted out.

I see the appeal, but I have to demur. My worst experience with this
was using an ext directory for disparate JDBC drivers while evaluating
database portability. Then I forgot that the drivers were there. Then I
added new versions of some drivers to the classpath. Although I
understood the resulting errors poorly at the time, I seem to recall
the class loader being unhappy. In retrospect, this was clearly
operator error, but it was a deceptively easy path to JAR hell:

<http://en.wikipedia.org/wiki/Classloader>

 

[Lew]

Package/class qualification doesn't distinguish between different versions of
the same JAR, one of the myriad risks of extension directories.