The depedency graph utility of CodeFalcon will parse through the source files and extract a dependency graph between the classes. Each node in the graph is a class (A), and each directed edge is a call from the class (A) to a function in another class (B). The colors of the edges are a coarse indicator of how many times class A calls a function in class B, with black/purple being the least to red being the most. If the result of the call to B.func is simply an object of another class (C) that then is used to call a function in it, then the it is logged as a dependency on C, rather than B. The output on some real-life (but to be unnamed code) is shown below.

Output of ./JavaGraph —show-only-cycles

You can note two things about the code base from this graph. First, it is easy to tell which classes are important: just look for the ones with a lot of lines either coming or going. (Above a certain threshold of edges, the node is made twice as high, making it even easier to spot)  If you are just starting in a code base, these are classes that are probably the best to look at, since the rest of the code frequently refers to them. The second thing to notice is that it detects cyclic dependencies. (In fact, this was generated with the —only-show-cycles option.)  If your code has any cyclic dependencies, it may simply manifest itself in a vague feeling that the code is hard to understand. This utility will reveal the structure of the cycles and make it easier both to understand them and to know where they are occuring so that you can break them.

Zoomed output of lower left

The second image is a zoomed in portion of the original image, and we can see here how easy it is to identify cycles. We can see that W, PM are pretty tightly coupled. If we could reveal the source, we would find that W own a VM. According to the output, W only makes 7 calls to VM, but VM makes 22 calls back to its owner! This suggests that W acts kind of as a global variable for VM. GI, DSH, and VA are a strongly connected graph, so obviously we need understand all three in order to understand any one, with the added complication that there are dependency cycles to W and ISD as well! Obviously this piece of software was very poorly designed, but it might be the case that refactoring is not possible for business reasons; at least now we know the structure. And if a refactoring becomes feasible, it is obvious where to start.

This tool is available as the JavaGraph tool in the CodeFalcon source. For information on building and running, please download the source and read the README.txt file.