Getting Rid of Redundant Jars.

[AmitDua Dua]

How can I determine which all classes and jars my Java program is referencing
from a all the jars in class path ?

[Bear Giles]

<code>java -verbose:classes [rest of args...]</code>

Important: this will only show the classes that you actually use during while the application is run. It will miss classes that your code uses, but which you don't actually trigger, e.g., for reports.

Another approach is to implement your own ClassLoader that defers to the parent class loader, but which logs which classes are requested. This is more flexible, but won't catch all files.

The other approach is to use reflection to recursively inspect the class files, but that will 1) be hard and 2) pull in a lot of stuff you don't use.

[Campbell Ritchie]

. . . and welcome to the Ranch

[Thomas Thrien]

For non-simple programs that's nearly impossible. The response above shows how to determine which classes are used during one single invocation; another invocation with other parameters may need other classes because other functionality is used.

Analyzing the code using reflection is also not feasible if advanced features are used (where advanced features start already with stuff like XML and JDBC).

JDBC is a good sample to explain why this causes problems: The old way to configure program with the JDBC driver was to call Class.forName( "JDBCDriverClass" ). Obviously there is no reference to this class in the binary code of that program. And when the name of the JDBCDriverClass is not hardcoded but read from somewhere, the program will never have any static reference of any kind to the jar holding the JDBC driver.

Similar scenarios can be found for XML parsers, Script engines, JNDI providers, Security providers, Encryption providers, Codecs, URL protocols ... I bet I missed a few ...

This also shows that different sessions with a program may use different classes from different jars: just assume a program like Squirrel that can be used to visualize different RDBMS databases.

On the other hand, if you have a simple, straight-forward program that does not use any kind of runtime plug-in mechanism, it could be possible to determine the really necessary jars: when you compile start with an empty CLASSPATH and add the jars until the compiler does not complain any longer.
This can be done also with running the program, but you may get surprised if someone uses a function that was not included into your tests - and now causes a CNF-Exception. But again, this will only work for really straight-forward programs.

[Stevi Deter]

For complex projects, one tool I highly recommend is Apache Ivy, which works well with ant build scripts and lets you create nice dependency reports. It does take some time to set up, but once it's done, it can really help reduce jar bloat.

[arulk pillai]

For complex projects, one tool I highly recommend is Apache Ivy, which works well with ant build scripts and lets you create nice dependency reports. It does take some time to set up, but once it's done, it can really help reduce jar bloat.

Interesting !! I will give it a try.