Tracing Java Execution Five Easy Ways

Discussions

News: Tracing Java Execution Five Easy Ways

  1. Tracing Java Execution Five Easy Ways (10 messages)

    Zviki Cohen describes five ways to trace Java program execution that you can apply depending on the situation at hand and the tools that you have available.
    I'm often faced with a situation where I need to dig into code that I didn't write. Most of it is poorly documented and, in some cases, I only have some of the sources, which means I need to decompile the rest. It's a tedious exploration. There are mainly two reasons for that: maintaining code or using it... I usually find that it is faster to trace the code at runtime. Especially when it comes to non-trivial links between classes, like an interface with multiple implementations which may be picked at runtime.
    Cohen goes on to describe when and how to use each of these methods: * Basic - breakpoints * Primal - debug messages * Hot Shot - dynamic proxy * Brute Force - run-time profiler * New Age - through aspects The posting closes with recommendations of when and how to trace complete execution or discrete events.
  2. AOP is still far from the mainstream. It is uncertain whether it will ever get there
    Not sure about that statement. AOP is being used in various industries. It may not be full blown AspectJ but other AOP approached (Spring proxy based). Another thing to point out is that you can use AspectJ to trace code within a jar. There is a aspectj compiler option.
  3. MaintainJ traces runtime Java execution using AspectJ runtime weaving and generates sequence diagrams. The sequence diagrams are easy to read and help to unravel complex Java code very quickly. I tend agree with the view that AOP is not yet widely adopted by Java developers. But with MaintainJ one doen't really know any AspectJ. It generates the aspect that is required for tracing. Yes, AspectJ can be used to trace either Java code or jar files. And you don't need to touch the Java code at all. MaintainJ also helps to trace multi-threaded applications. It generates separate sequence diagram for each thread in the use case. These diagrams can be merged if needed. These features help to quickly debug multi-threaded applications. Check the video demos to get a quick overview. Choudary Kothapalli. MaintainJ Inc.
  4. For some types of problems I am pretty fond of the Omniscient Debugger http://video.google.com/videoplay?docid=3897010229726822034
  5. Even though they might be a subset of profilers, I think code coverage tools should be on the list. In the past few weeks Intellij Idea's code coverage visualization (integration w/ EMMA) has been a valuable tool in handling a convoluted codebase (minimal documentation, complex implementation). When I run integration tests in Idea, Idea starts collecting coverage data. After the run is finished, Idea marks lines with green or red depending on if the line was processed or not. It also shows line and class coverage as percentages. The visualization makes it pretty easy to see what was executed. If a conditional branch is red, it's not executed. If a whole method is marked with red or a class has 0% line coverage, it might be something which is not covered by the tests or it might be unused code and it can be removed. The codebase I'm working with is so complex that analyzing different execution paths and permutations would have taken ages without that feature. The only downside to using code coverage visualization is that it's a bit of macro level tool, you get a nice overview of things but smaller details are better handled with other tools.
  6. One thing I didn't see mentioned that I've used when trying to trace how a certain method is called in spaghetti code: try { throw new Exception(); } catch (Exception e) { e.printStackTrace(); } Ugly but quick and effective and works in any version of Java. Really helpful for narrowing down the problem area. The other thing that this article doesn't touch on is debugging multi-threaded issues. Debuggers are basically worthless in this case. Profilers change the timing too much. I'm not sure how well dynamic-proxies and aspects work for debugging multi-threaded code. Anyone have any experience with this?
  7. You can print an exception's stack trace without throwing it, for example: new Exception().printStackTrace(); If you want to get a stack trace as a string, do the following: StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw); new Exception().printStackTrace(pw); pw.flush(); String stackTrace = sw.toString();
  8. One thing I didn't see mentioned that I've used when trying to trace how a certain method is called in spaghetti code:

    try {
    throw new Exception();
    } catch (Exception e) {
    e.printStackTrace();
    }
    Or, you could just do this: new Throwable().printStackTrace();
  9. One thing I didn't see mentioned that I've used when trying to trace how a certain method is called in spaghetti code:

    try {
    throw new Exception();
    } catch (Exception e) {
    e.printStackTrace();
    }


    Or, you could just do this:
    new Throwable().printStackTrace();
    Or you might call Thread.getCurrentThread().getStackTrace() to get a list of stack trace elements. This however, only works in 1.5 and above I think.
  10. Or, you could just do this:
    new Throwable().printStackTrace();
    Sure, but it makes no real difference and the try catch block stands out better when you go back and clean up. I thought that I had tried that in the past and it didn't work properly in certain environments but in the end the result is the same.
  11. Heatlamp will trace Java executions and generate a rich interactive diagram of running code. The diagram is searchable, collapsible, zoomable and pannable. You can find a free download on the website:

    http://www.jmolly.com/heatlamp/