Too damned many jar files

[Luke Webber]

I just had the great joy of deploying a simple webapp that uses SAAJ.
Care to guess how many jar files it needed? 24!

I suppose I might have been able to dispense with some of these, but I
honestly don't know which ones might be surplus to requirements, and I
don't have time to try taking them out one at a time to find out. Hell,
it even barfed because it didn't have the JavaMail API, and I'm damned
if I know why it would need that.

This situation seems to be getting worse every month. There are so many
dependencies from one project to another, some requiring things like
Xalan or Xerces and/or some of the Commons libraries, and others needing
Crimson or JavaMail or what-have-you. It's a real mess.

When the Java extension mechanism came out, I thought that would make
things better, but instead things got steadily worse. Whenever I added
something to the lib/ext folder, there was a good chance that something
else would break. A good example is those XML parsers, which broke both
Eclipse and Tomcat when I loaded some into lib/ext.

Does anybody have any suggestions for simplifying my life, or it this as
good as it gets?

Luke

 

[Stefan Ram]

This situation seems to be getting worse every month. There are so many
dependencies from one project to another, some requiring things like
Xalan or Xerces and/or some of the Commons libraries, and others needing
Crimson or JavaMail or what-have-you. It's a real mess.

Called "reuse" by others.

Isn't this what we all want: The silver-bullet.

Do not write code, but reuse code written by others.

So why complain, if it really happens?

something to the lib/ext folder, there was a good chance that something

Usually it is recommended to use the option »-classpath« or
»-cp«, not the directory lib/ext. (IIRC for the reasons
you give.)

Does anybody have any suggestions for simplifying my life, or
it this as good as it gets?

If you do not want to write everything yourself, you need to
reuse code written by others. Whats the effort to install 24
jar files compared to the effort to write it all oneself?
Shouldn't you be more grateful to all those parties making
available all these jars to you instead of complaining?

You might like this article:

http://www.itworld.com/nl/xml_prac/04182002/

 

[Pickles]

I just had the great joy of deploying a simple webapp that uses SAAJ.
Care to guess how many jar files it needed? 24!

I suppose I might have been able to dispense with some of these, but I
honestly don't know which ones might be surplus to requirements, and I
don't have time to try taking them out one at a time to find out. Hell,
it even barfed because it didn't have the JavaMail API, and I'm damned
if I know why it would need that.

This situation seems to be getting worse every month. There are so many
dependencies from one project to another, some requiring things like
Xalan or Xerces and/or some of the Commons libraries, and others needing
Crimson or JavaMail or what-have-you. It's a real mess.

When the Java extension mechanism came out, I thought that would make
things better, but instead things got steadily worse. Whenever I added
something to the lib/ext folder, there was a good chance that something
else would break. A good example is those XML parsers, which broke both
Eclipse and Tomcat when I loaded some into lib/ext.

Does anybody have any suggestions for simplifying my life, or it this as
good as it gets?

Luke

 

[Pickles]

Sorry for the incorrect previous post - please ignore.

Why would one want to deploy code not related to the core application?
I would rather write the code myself than deal with unknowns.
You would think that our community would require all contributors to
list their library dependencies first, so that you can decide if you
want to implement their classes.
You also get what you pay for. It probably is worth it to get a
reasonable commercial XML parser. What you pay for in cash you save in
administrative headaches and sleepless nights wondering how much of
this new code is actually needed.

Based on what little I know about J2ME, is that code has to be tight -
you can't have code in memory that is not earning it's keep and
contributing to the application. I also don't want to have to change
too much code while supporting customers in both environments.

Do I know what I am talking about? Not necessarily, but after many
years of development, code is code and memory is memory. It appears
Java is no different in that it too is developed by independently
thinking humans.

Once person's code is another person' s poison.

 

[steve]

I just had the great joy of deploying a simple webapp that uses SAAJ.
Care to guess how many jar files it needed? 24!

I suppose I might have been able to dispense with some of these, but I
honestly don't know which ones might be surplus to requirements, and I
don't have time to try taking them out one at a time to find out. Hell,
it even barfed because it didn't have the JavaMail API, and I'm damned
if I know why it would need that.

This situation seems to be getting worse every month. There are so many
dependencies from one project to another, some requiring things like
Xalan or Xerces and/or some of the Commons libraries, and others needing
Crimson or JavaMail or what-have-you. It's a real mess.

When the Java extension mechanism came out, I thought that would make
things better, but instead things got steadily worse. Whenever I added
something to the lib/ext folder, there was a good chance that something
else would break. A good example is those XML parsers, which broke both
Eclipse and Tomcat when I loaded some into lib/ext.

Does anybody have any suggestions for simplifying my life, or it this as
good as it gets?

Luke

i'm up-to 150. jar files.
From an enterprise viewpoint it is a killer nightmare for control and
maintenance.



the only way i have found to do it and keep it working. (without using java
webapp)

It's called "steves power loader" ;-)

1. store the .jar files in an oracle database
2. index them.
3. store a nested tree view of what each jar uses, as regards to other jars.
4. when i update a jar, i also update the other jars that it uses ,
(basically by deleting the master jar , and its list of requirement .jars) ,
then i re-add the new version along with its new required jars)

5. re index , dropping any jars that are not linked into the roots.

my 1 big problem is when authors do not use a sensible revision system for
their names, i have to go thru manually updating sometimes, takes maybe 10
minutes.


then my main app consists of 4 files which i distribute to the users via
email.

1st is a boot loader that connects to the oracle database and pulls the jars
that are needed ,and writes them to the users local workstation.
2nd is a re-launcher
3rd is oracles java drivers
4th is a text control file.

whenever a jar in the database is updated, it is pulled to the workstation
automatically


I had tried to get in touch with sun & a couple of public library writers
with a proposal, to add a call to their libraries that returned a list of the
jars their library required, but it just seems they are happy to stick all
the shit in a directory, and let the classloader/compiler figure it out.

Steve

 

[Chris Uppal]

Called "reuse" by others.

Or "laziness" or "punting the problem to the user" by others still. My
impression of the free software world (not limited to Java) is that they are
far too fond of reuse. Nothing wrong with reuse /per se/ but if it hinders
adoption then it's gone too far.

Putting it rather uncharitably, they confuse "I've got X on my machine" with
"everyone has X on their machines (or damn well should have!)".

The same thing is happening with the specification world -- there is /way/ too
much interdependency between the new generation of XML-based specs, for
instance.

Isn't this what we all want: The silver-bullet.

Ain't no such thing ;-)

More seriously -- wouldn't you agree that interdependency between code is part
of the reason why it's hard to make software scale ? And the "install
everthing or nothing will work" syndome is certainly a symptom of
interdependency.

Shouldn't you be more grateful to all those parties making
available all these jars to you instead of complaining?

Put it this way: could they /sell/ code in that condition ? If not, then in
what sense of "badly written or designed" is it not badly written or designed ?
Being free is no excuse for poor quality.

(I am, of course, taking an extreme position here for the sake of debate ;-)

You might like this article:

http://www.itworld.com/nl/xml_prac/04182002/

Interesting read; I found myself nodding sagely all the way through ;-)

Don't be afraid to reinvent wheels. (After all, car manufacturers -- who
surely know more about wheels than most -- rarely reuse a wheel designed for
one car on a different line.) If you can make a wheel that is any of:
rounder
simpler
cheaper
then don't let the nay-saying moralists of the computer industry put you off.

Wheels are good. More wheels are better. Invent early; invent often !

-- chris

 

[Chris Smith]

Called "reuse" by others.

Isn't this what we all want: The silver-bullet.

Do not write code, but reuse code written by others.

So why complain, if it really happens?

I'll side with Luke here, and my concern is more limited. Ideally, if I
needed to solve a substantial problem, and that problem had already been
solved by someone else, and I could use their code instead of writing it
myself, that's great.

Then, there's reality. In reality, there are gazillions of dependencies
that are just silly. The code that is "reused" doesn't actually do
anything at all! The worst offenders here are Apache's Jakarta
(commons-logging, to take the worst example) and Sun with J2EE-ish APIs.
These additional dependencies often provide nothing except an overly
general and complex API to something that any competent programmer could
have written in an afternoon.

Not that I think it should be any harder to manage 24 JAR files than it
is to manage 5, if the deployment is sane and thus doesn't require the
user to find and install all of them.

 

[Andy Flowers]

I had tried to get in touch with sun & a couple of public library writers
with a proposal, to add a call to their libraries that returned a list of the
jars their library required, but it just seems they are happy to stick all
the shit in a directory, and let the classloader/compiler figure it out.

Steve

Take a look at JSR 277, http://www.jcp.org/en/jsr/detail?id=277, which shows
that someone is interested in the same kind of problem.

(Probably driven by the .NET GAC on windows ?)

 

[steve]

Take a look at JSR 277, http://www.jcp.org/en/jsr/detail?id=277, which shows

that someone is interested in the same kind of problem.

(Probably driven by the .NET GAC on windows ?)

well that could be really cool.
unfortunately if it is anything like the USB standard , then were in for 5
years of puffing and blowing.
however i 'm going to keep my eye on it.

 

[Dale King]

I just had the great joy of deploying a simple webapp that uses SAAJ.
Care to guess how many jar files it needed? 24!

I suppose I might have been able to dispense with some of these, but I
honestly don't know which ones might be surplus to requirements, and I
don't have time to try taking them out one at a time to find out. Hell,
it even barfed because it didn't have the JavaMail API, and I'm damned
if I know why it would need that.

This situation seems to be getting worse every month. There are so many
dependencies from one project to another, some requiring things like
Xalan or Xerces and/or some of the Commons libraries, and others needing
Crimson or JavaMail or what-have-you. It's a real mess.

Does anybody have any suggestions for simplifying my life, or it this as
good as it gets?

You should really checkout Maven. It makes dependency management a
breeze. You just specify what your dependencies are in the Maven POM and
it handles, downloading them from the public Maven repository and using
them for its own builds. I believe its war plugin would then copy them
to your WAR file. There is even an Eclipse plug-in where it will get its
dependencies from the Maven project file.

Check it out at http://maven.apache.org

Note however that due to Sun's license restrictions they can't put Sun
libraries (like JavaMail) in the public Maven repository, but that can
be worked around. You can put them in your own local repository. See:

http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html