Find Most Frequently-used Java Methods in Eclipse Workspace

Question

Is there an Eclipse plug-in, or some other tool or technique that would search an entire Java project (and/or the entire workspace) and reveal (in list/sortable format) the frequency-of-invocation of all public methods in the project? That is "what code is using what other code" the most?

I'm very familiar with the CTRL-SHIFT-G or CTRL-G usage; use it all the time. I'm also familiar with the Call Hierarchy view. The result that I'm looking for could be described like doing Search > References > Workspace (CTRL-SHIFT-G) on every method in every class in the workspace and tallying/counting the number of results each time, with final, sortable output like the example below.

The notion above is to get an idea of which classes/methods are getting most-used (not at run-time; in this question "used" != "executed"), in order to prioritize unit-testing on a very large project. I want to start using JUnit more (more than not-at-all, that is), and the idea of finding the most-used methods seemed like a good place to start.

For example, given three classes, ClassA, ClassB, and ClassC, I'd like a summary similar to this:

    Method                                       Number of calls
    ClassB.methodThatDoesSomethingMundane()                  134
    ClassC.methodThatDoesCoolStuff()                          78
    ClassC.methodThatDoesImportantThing()                     71
    ClassA.constructor()                                      63
    ClassB.aDifferentBoringMethod()                           37
    ClassA.getSomething()                                     19
    ... etc ... 

Answer 1

JArchitect, a commercial product, seems to have an interesting metrics module:

Method rank: MethodRank values are computed by applying the Google PageRank algorithm on the graph of methods' dependencies. A homothety of center 0.15 is applied to make it so that the average of MethodRank is 1.

Recommendations: Methods with high MethodRank should be more carefully tested because bugs in such methods will likely be more catastrophic.

I did not test it, but it worth a try.

But I don't think it will work if you use Java reflection.

Answer 2

You could use a profiler (for example VisualVM, jvisualvm.exe in jdk/bin/ folder) for that.