An existing application has a ton of JAR files in its classpath. Someone must have added all JARs initially just to be sure. Some of the JARs were obviously not being used and w
I used the following shell script in a jboss portal project to get the list of jar files that are used in import statements. This will of yourse only work for direct dependencies, not for dynamically loaded or even when the fully qualified classname was used in the source. Furthermore, all jar files and their transitive dependencies are provided by the container so they are only needed to compile the code.
The goal was to create a maven pom for the project and to find the files that needed to be deployed to our nexus repository manager. It might be useful as a starting point to list the files that are definitely needed, the remaining jar files would have to be checked in other ways. If the jar is also available in a maven repository you might look at its dependencies for example.
#!/bin/sh
JBOSS_HOME=/path/to/jboss/installation
JBOSS_LIB=$JBOSS_HOME/server/default/lib
JBOSS_DEPLOY=$JBOSS_HOME/server/default/deploy
SRC_DIR=src
for f in $JBOSS_LIB/*.jar $JBOSS_DEPLOY/jboss-portal.sar/lib/*.jar $JBOSS_DEPLOY/jboss-portal.sar/portal-cms.sar/lib/*.jar $JBOSS_DEPLOY/ejb3.deployer/*.jar
do
for c in `jar -tf $f | tr '/$' '..'`
do
#echo "^import ${c%.class};"
if `grep "^import ${c%.class};" -h -r $SRC_DIR -q`
then
echo $f $c
fi
done
done
If any of them are loaded dynamically, it's possible that automated tools will miss them. I would reset the access times on the files, run the application for some time (and make sure to invoke as much functionality as possible), and see which files were accessed and which were not. You may need to repeat this on each platform your application needs to run on, just in case.
Be aware that trial and error alone can be a problem, especially if the application loads classes dynamically (e.g. Class.forName
) as removing a JAR might not prevent the application from starting up and (apparently) work fine, but it may fail later if target classes are not found.
Also, there are many tools that can be used to analyze a Java application and find out dependencies (I have used Dependency Finder myself, although not exactly for this purpose), however note that most of them will also fail to find classes that are loaded dynamically as described above.
Tattletale is a great tool for this. It works on the bytecode, so it is possible, that some classes are use via reflection and will not come up in the report.
Here (link no longer works) is an example report. As you can see, you just have the feature you are looking for "Unused JAR".