Tool to remove unnecessary dependencies in a Java

Question

I have a Java project that currently has a lot of JARs in its libraries directory, which are all included in the resulting package when building. I know, however, that some of these libs are never referenced in the project.

Is there a tool that can search for libs that are not referenced within the project? I guess there must be something in that sense.

BTW, an Eclipse plugin would be awesome.

EDIT: I chose to go with ClassDep because it was the only suggestion that worked. However, I'm having some trouble with it: please check this question

Answer 1

You also can't tell if JARs that you don't import are required dependencies of dependencies. For example, if you use Spring it comes with its own dependencies, even if you don't import or call those classes in your code. I'm ignorant of ProGuard - does it check for those cases?

Answer 2

Not an eclipse plugin, but I believe the "shrinking" functionality of ProGuard is exactly what you're looking for.

Answer 3

ClassDep (from Sun, in the Jini development kit) will do this for you.

Answer 4

ClassPathHelper can help you with that.

Espacially the "Not on Classpath View"

This view scans for jars that are not on the classpath (but are under the current project). It provides basic browsing of packages and classes that are available but not on the classpath. This can be helpful when trying to build up a classpath, as you can quickly browse for the missing classes to see which jars contain them.

Answer 5

I wrote a small eclipse plugin that takes an existing java project from the workspace. For every classpath entry of the projects raw classpath it removes it from the projects raw classpath and builds the project. If no problem markers with severity error appear on the project, it permanently removes the classpath entry from projects raw classpath.

I'm not able to share that plugin, but that is not too much work to implement it yourself with the links to the api given above.

Answer 6

Beware of the case that a class is loaded via Class.forName() and not specified as a dependency in the manifest file (there is a Depends-On: attribute that is for that, but many people don't specify it, which breaks tools like this, the bane of my existence when I worked on such a tool).