tags:

views:

371

answers:

4

I am currently working on an application which is around a decade old. When I looked in to the jar files which are associated with the application , I can see lots of jars which are not required and lots of different versions of same jar.

What are the cons of having unwanted jars in lib. What is the easy way to find and remove them?

+4  A: 

You might get problems if a class loader decides to load classes from different version of jar file than you expect. These kind of problems are usually hard to track. Server will look through jars in some specific order (alphabetically by filename?) and use the first matching class/resource it finds. There are probably no guaranties that the newest version of a jar file is looked first.

I do not know of any tools that would find out which jars are unused. That may be impossible in general case due to reflection, but some degree of automatic checking should be possible, at least in theory.

Removing unused jar file by trial and error is problematic if you do not have good unit tests, which I doubt you have in your decades old application. There may always be some rare error case that depends on just the old jar version you just removed.

Juha Syrjälä
Ok cool .. Thanks.
Umesh
A: 

By unwanted jar files in your application, do you mean that these are generated as part of your compile and build process every time? If so, then it might be the build scripts that you want to clean up.

If you are referring to the actual deployment environment, then any cleanup must be done very carefully. Why not try starting over in a fresh test environment with a clean tomcat installation and the latest build's executables deployed? See if it runs well on just that, and if it does, then maybe the extra jars are indeed unnecessary.

As for the cons, I don't see any aside from the filesize of your deployment.

Jeremy
what i meant by unwanted jars is jtds1.2.jar and jtds1.2.2.jar is there where 1.2 is not used. We are using jtds kind of connection for last six months. But it still contains the mssql.jar etc.. which were getting used before that. There are no files getting generated as part of compile/build.
Umesh
A: 

How can you decide which of the jars are not being actually used?

I would suggest making this a full QA-needing change. You have no idea if the code chosen from the set of jars shadow an erroneous implementation surfacing if you remove an "obsolete" jar.

Thorbjørn Ravn Andersen
+1  A: 

My suggestion is that if your applications are working, leave the jars as they are now. It will be very troublesome if not impossible to find out, which jar files are actually picked up by the class loader. (Of course do not deploy new applications).

You can find which packages a jar file contains by using JarAnalyzer. This will give you an idea of duplicates and you can start removing older versions of jar files. However this procedure needs to be done by hand and by trial and error. Also, the same package may be contained in two jars with different names and no versioning information.

As already said having different versions of the same jar could bring havoc. You can't know which version will actually be used and what conflicts it will bring to this or another application. That's why you should never use Tomcat's shared folder for applications jars. If you are in a situation, where many jar files are placed in the shared folder, avoid using this server for new applications.

kgiannakakis
For now i have only one application running under the tomcat. But the reason for including jars in tomcat shared path is, some jars tomcat wont take while residing in application lib. Ex: jtds.jar, mysql v 5.4 jar. If you put these jars in application lib and try to connect to database, it will throw exception. (It never worked for me. For a solution, i copied it to tomcat lib and it started working. )
Umesh
If you are using a JNDI resource to configure a datasource, then the jdbc connector must be in the shared folder, so that the jar file is present before your application starts. This is an exception to the rule. Do not place jars in the shared folder, unless this is absolutely necessary.
kgiannakakis