Question

I have to refactor and maintain a bunch of horrible similar looking Java classes. Many have the following implementation pattern

class Machine {
    public int advance(int state) {
        switch(state) {
        case 7:  return step_7();
        case 13: return step_13();
        case 4:  return step_4();
        }
    }
    private int step_7() {
        if(something) return 13; else return 4;
    }
    private int step_13() {
        ...
        return 4;
    }
    private int step_4() {
        if(miep) return 7;
        ...
        return 13;
    }
}

And from this I’d like to generate a graph (with Graphviz and dot) — sort of a “static call graph”, but not exactly.

I am game here how I can do this automatically, besides using Perl or Python parsing the Java code myself.

What I’d really like to to is to have an Abstract Syntax Tree (AST) or something similar of the class I could navigate through and while doing that printing the dot-code.

• How can I produce a traversable AST here? I guess the traversing would be done in Java then, but if the output is any text representation it would be ok (gprof comes to mind here).
• Any other approach, not using AST? Maybe I am just blind and there is a better, simpler way to do it.

Answer 1

There are a variety of Java parsers around that will produce ASTs:

• Eclipse JDT
• ANTLR
• (Our) DMS Software Reengineering Toolkit

But ASTs are hardly ever enough when processing a real computer language. For instance, to determine what methods a call site may invoke, you need full name and type resolution so that you can accurately determining which foo of the thousands of foos lying around in your source files might be called. This isn’t easy to compute for Java because of its complicated lookup rules. For more details on this topic, see my essay on Life After Parsing. You are not likely to duplicate such features easily by just hacking in Python or Perl, unless you don’t care about the accuracy of your answer. Eclipse JDT probably has name resolution; I’m not sure. The ANTLR Java parsers do not; they just parse.

DMS’s Java Front End has full name and type resolution for Java. To determine your call graph statically, you need essentially a points-to analysis; each field that contains an object of any kind is essentially a pointer, and you want to know for each pointer, specifically which objects it might select, and then you need to construct a (global) call graph to get the basic information you want. DMS’s provides support for computing various kinds of control and data flow analysis; the Java Front End provides basic flow facts and it will compute local data flow analysis. To get a points-to analysis, you must assemble these facts with DMS’s help, and then construct that call graph. We don’t do this with DMS yet for Java, but we have for C on enormous scale (26 million lines in one system), and an analog for Java would be pretty similar and use most of the same DMS mechanisms; the call graph construction is fairly easy once you have points-to analysis. We’ve exported such graphs as DOT-graphs; you need to filter them to get a subgraph that DOT can actually afford to render.

You might be able to collect flow analysis facts from class binary analysis files such as Wala. You’ll still face the problem of construction of points-to analysis and the global call graph. I recall that Wala has some kind of help here, but I don’t recall what.

You could perhaps collect a dynamically-constructed call graph using a profiler tool. Such a call graph is likely to be pretty incomplete unless you carefully exercise all your system functionality during the profiling process; that’s pretty hard to do.

Eventually, you’ll probably want to change your code. Maybe you want to inline your stepN functions. Maybe you want to do it by hand, but if your code is full of such things, maybe you want automation. Here a tool like DMS provide source-to-source transformations, enabling such automated code changes. Wala won’t help you here.