View Image

Dependency Finder is a suite of tools for analyzing compiled Java code. At the core is a powerful dependency analysis application that extracts dependency graphs and mines them for useful information. This application comes in many forms for your ease of use, including command-line tools, a Swing-based application, a web application ready to be deployed in an application server, and a set of Ant tasks.

JarJarDiff is another important tool in the suite. It compares two versions of the same codebase and reports the differences in the API. It lists new, changed, and removed elements such as packages, classes, methods, and more. You can tailor the reports to focus on your public, published API versus the private, internal one.

Finally, Dependency Finder has a tool for computing object-oriented software metrics that give you an empirical quality assessment of your code. Once again, you can tailor the report to focus on the metrics that you care about and adjust validity thresholds to the specifics of your project.

Why use Dependency Finder instead of the alternatives?

Dependency Finder is not the only game in town. Tools like IntelliJ and Xrefactory have great features that let you track down usage of selected classes or methods. So why should you bother with yet another tool?

By the way, I keep an informal list of the competition on the resources page.

For starters, Dependency Finder is free. Free as in "free beer" since it costs no money; and free as in "free speech" since you can get the sources and do whatever you want with them (except take my name off, that is).

Dependency Finder has a powerful querying mechanism based on Perl regular expressions. Whereas other tools can show you usage for a single method, Dependency Finder can show you usage for many methods, and possibly all of them, at a single glance. For example, "Show me all calls to constructors of this class." With other tools, you have to select each constructor in turn, have the tool generate usage information for it, save the results, and aggregate them later somehow, if at all. I don't know about you, but I have more important things to do, like fix bugs and write new feature.

The web application lets you share a dependency graph with your entire team. Anyone can query the graph with nothing more than a browser. They don't have to install anything or wait after the tools to extract a graph from code. The graph is there, all the time, at everyone's disposal. You can even have your nightly build regenerate the graph after each successful compilation run.

Dependency Finder can compute closures, that is, follow dependencies and find everything reachable from a given start point. This can help you package related components together, or verify that your code respects encapsulation.

And Dependency Finder includes many more tools. See the user manual and the tool list for all it has to offer.

Why bother with dependencies at all?

Many authors have stressed the importance of managing depencencies (Robert C. Martin, John Lakos, Martin Fowler). Managing dependencies means securing encapsulation and making sure that the code follows the architecture. It is also essential for the modularization of code and favors reuse. By extracting the information from the code itself, we can detect where we were sloppy, where we took shortcuts that we shouldn't have. Managing the dependencies can even shorten the compilation time of the code.

At first, I thought of using the Reflection API, but it showed only the class's attributes and method signatures. If a method used some other class for a local variable or called a static method, that dependency that would not show under the Reflection API. So I had to build a suite of tools that could extract dependencies from compiled Java code directly. The tools can get all the necessary information out of the .class files.