Product Reviews

It's unnecessary but true: a lot of Java programmers still debug by putting System.out.println() statements in their code to find out what the program is really doing and where the problems are. To overcome this antiquated approach I've tried several debuggers: Sun's JDB is free but cumbersome and hard to work with. Visual SlickEdit, my favorite IDE, has integrated debugger support but is also difficult to run. Metamata debugger was my next choice but the product went away. So I searched the Web for options and, indeed, there is a better way: RetroVue from VisiComp. It creates a complete journal of your program's execution, letting you go back to any previous instance and examine the state back then. These features and some articles about "Omniscient Debugging" aroused my interest in RetroVue.

In this article I try to explain the difference between RetroVue and other debuggers. Then you, the reader, can decide if it's worth paying $995 for it.

Omniscient Debugging
RetroVue is built on the concept of Omniscient Debugging. The idea is to collect operations at each "point of interest" (setting a value, making a method call, acquiring/getting a lock, throwing/catching an exception) in a program and then allow the programmer to use those events to explore the history of the program. A free (GPL) experimental debugger called ODB (written by Bill Lewis) is an implementation of this idea (www.lambdacs.com/debugger/debugger.html).

VisiComp Inc.'s software analyzer RetroVue 1.1 is a full-fledged product, also written in Java, with a strong graphical user interface based on Sun's Swing library. It works by inserting byte codes into the application's class files. This code collects information on each point of interest as mentioned. Collected events or operations are stored in a log (RetroVue calls it a journal file) and then displayed in GUI. A programmer can use the GUI to review the behavior of objects, variables, and method calls. This means that you see which values are bad, find out where those values came from, and who set them and why. This also means that there are no nondeterministic problems. You don't have to guess where the problems might be; you don't have to set breakpoints; you don't have to wonder which threads ran when; and you don't ever have to repeat a program run.

Where Am I? - Breakpoint Debuggers and Flight Recording
With traditional debuggers the programmer generally only knows that the program is stopped at a given breakpoint, but not the states leading up to the break. Omniscient Debugging can solve this problem. RetroVue is characterized by VisiComp as a "Total Recall Debugger" for Java developers. This hints at where the tool is positioned in the software life cycle: early in the development phase. There are other "flight-recorder" tools like RootCause (www.ocsystems.com/prod_rootcause.html), designed to simplify tracing and data collection in a post-development environment, i.e., in the production environment. Once an application transitions to testing, integration, or QA, development tools are no longer appropriate. They place too much load on the system. That's true for RetroVue because RetroVue logs and gathers data from nearly all aspects of the Java app's execution. There is a lot of similarity in the underlying technology but RetroVue is intended to be a developer's tool, to be executed in the development environment. The price the developer has to pay is performance, i.e., RetroVue slows down execution and perhaps needs an additional disk for its journal file. This is because RetroVue works on a disk-based model rather than a memory-based one. The current version of the product only loads what it needs into memory, chucking what's no longer necessary to make room for stuff that becomes needed as the user examines further events. However, the bigger the journal file, the larger the amount of information that's required. RetroVue can work with huge journal files where the actual limit depends on the particulars of the journal file contents. Of course, if the size of the working set exceeds the actual RAM in your machine and the underlying virtual memory subsystem is heavily utilized, performance will drop off rapidly. Thus RAM does really matter and I recommend having at least 512MB.

Facts and Features
As mentioned before, RetroVue instruments your Java byte code, either on the fly as the program is running or offline from the command line. Unlike conventional debuggers, RetroVue keeps track of every operation executed by your program. By maintaining a complete journal of every assignment to every variable, each method invocation and return, each thrown and/or caught exception, each thread switch, each lock operation (e.g., when executing synchronized methods, etc.), RetroVue allows you to scroll forward and backward in time and lets you examine the state of your program at any given instant. Its powerful and intuitive Swing GUI lets you scroll time as easily as you scroll text in an editor. The GUI is based on VisiComp's visualization software, which uses proprietary algorithms to show the mechanics of Java programs in a graphical format that displays the state, execution, and thread interactions of programs. The main screen is divided into different optional views. I used RetroVue on two different machines, one with a 15" monitor. My experience is that an 18" or 19" monitor is better suited for making all the interesting views visible at one time without the need for scrolling or resizing some panes.

The following panes are available (some are shown in Figure 1).

• Class Browser: To view and navigate the class hierarchy of your program. Only those classes currently loaded are accessible so you can't waste time looking for a bug in unused code.
• Search Results: Displays the results of search requests performed via a popup menu accessible in various other views.
• History View: Displays a "log" of every operation produced by the program being debugged. Change the variable historyview.showSequence Num=true in RetroVue's properties file (contained in retro.jar) to display event or operation numbers too. Perhaps this will be possible via the GUI Option menu in the future.
• Data View: The data for the current or selected method invocation frame. If the program being debugged was compiled with "-g", then the local variable names will be shown. If "-g" was not used to compile the program, the local variables' slot numbers will be used.

  When faced with a null pointer exception, RetroVue's "Show Previous Assignment" command in the data view makes it trivial to go back to the exact point where the variable was assigned a null value. By hopping backward in this way, it's easy to get from the manifestation of the bug (the symptom) back to when and where the problem actually occurred (the cause).

• Messages: Displays output, if any, from the program currently being debugged by RetroVue.
• Source View: Provides the text of the source files for your program. Source views will only appear if the Source Path preference was set when the program was launched under RetroVue. The Source View consists of different source viewers, one viewer for each source file being viewed. Each viewer is divided into two portions: the gutter and the text area. The user may set a breakpoint next to a line of code by clicking in the gutter. This breakpoint is a stopping point when navigating through the history view (see below).
• Thread View: Displays the chronological sequence of the information produced by your program, organized by thread. It provides a "high-altitude" overview of your program's information, rather than the detailed information provided by the History View. In the timeline at the top of this view, the numbers correspond to the same event ID numbers shown in the History view (when you have set the property historyview.showSequence Num=true).

The colored bars show the activity within a particular thread and certain interactions between threads. Multiple threads contending for more than one lock can lead to a programming bug known as deadlock, which is more technically defined as a "cyclic lock dependency." RetroVue automatically detects this condition and alerts you with a skull and crossbones icon. Figure 2 gives you an impression of the Thread View.

Navigation Through Time
In addition to finding bugs, RetroVue lets you validate the expected runtime behavior of your program. You no longer have to insert println statements or set breakpoints to verify that your program is doing what it is supposed to do. Instead navigate through the History View using commands like "Play," "Step over," "Step out," "Step into," or "Rewind". A rewinding facility like this has never been an issue in traditional "breakpoint" debuggers, so you have to learn a new "methodology" of debugging.

Installation and Getting Started
Installation of RetroVue is just a matter of seconds: download the appropriate installation file for your platform (for Windows, Unix, Linux, or Mac). Uncom-press the file with a decompression utility like Winzip or tar in a directory of your choice. That's it. You can then modify your program's start statement and RetroVue automatically comes up if your program exits (under normal and exception conditions; but if you cancel your program using CTRL+C or something similar you have to bring up RetroVue from the command line).

Modify your run statement as follows:

java -jar <retro-dir>\retro.jar -journal <journal-file> -sourcepath
<source directory> -exec -cp <classpath> -D<properties>
<your-main-class> <program arguments>

Besides the command-line launcher, RetroVue comes with a GUI launcher that serves as a front end to RetroVue's command-line options.

The documentation is provided as an HTML manual. It's enough for getting started, but I would prefer an additional "How to" section that describes some typical procedures when using RetroVue for different debugging problems.

Current Limitations and Future Enhancements
The current version, RetroVue 1.1.12, is not really intended for Java enterprise applications (RetroVue Enterprise Edition is on their schedule), but there are situations when you can use it even there. If you examine the run statement above you'll see that you can analyze part of your J2EE Web app if it's started as a process in its own JVM! Version 1.1.12 of RetroVue can only be used for postmortem debugging and analysis of an already-executed program. Future versions are being planned to allow interactive debugging of a running program.

Another limitation is that Java system classes like java.util.Properties are not augmented or tracked. This will be addressed in a subsequent release.

What I miss the most is a filter capability and a "Start/Stop-Recording" facility as in CPU-profiling tools. Adding another feature would be quite easy: changing the Swing GUI's look and feel. I'm not happy with the current Sun Metal L&F and I can imagine other users would also prefer having another choice. VisiComp's support team told me that all these wishes were on their list for future releases.

VisiComp, Inc.
6630 Highway 9
Suite 103
Felton, CA 95018
Web: www.visicomp.com
Phone: 831 335-1820
Fax: 831 335-7038

Specifications
Platforms: Windows, Unix, Linux, Mac with JDK 1.3+
Pricing: $995 per developer

Test Platform
Fujitsu-Siemens PC Scenic W600 with Intel Pentium 4 3,06GHz processor with 1GB RAM. Windows XP Professional SP 1.

Snapshot
Target Audience: Java programmers and developers
Level: Beginner to advanced
Pros:

Easy installation

Powerful and intuitive GUI

Easy to learn

Cons:

Not targeted at server applications

No filter capabilities

No instrumentation of Java classes

Summary
VisiComp's RetroVue debugger was featured in a James Gosling JavaOne 2002 keynote. Sun Microsystems vice president, distinguished engineer, and creator of Java said: "The work the folks at VisiComp have done is truly spectacular. It has a strong opportunity to dramatically improve the software development process."

I think if you are looking for a new debugging concept you should spend the time and money and try VisiComp's RetroVue debugger. If you're not fully satisfied - they give you a 30-day money-back guarantee (for certified users there is an evaluation copy available, too). Using RetroVue I was able to fix some horrible bugs in our J2EE Web app that uses an embedded Tomcat Server with different JVMs, each running different threads. I had to analyze a 38MB RetroVue journal file, but there were no problems with the program performance or the "speed" when loading the log file and working with RetroVue's GUI. However, I used a high-end PC running Windows XP with 3.1GHz CPU, lots of disk space, and 1GB of memory. As with a lot of tools: the more memory you have the better for RetroVue, but you don't have to adjust your java -Xms -Xmx options; this is done by RetroVue behind the scenes. On my home PC running Windows 2000 with 800MHz and 256MB memory, things looked a little bit different. It took about four minutes to load the 38MB journal file, and navigating in the GUI was significantly slower than on my high-end PC. The reason is simple: the total memory consumption was more than 500MB, although RetroVue's java.exe took only 48MB! Nevertheless, if you plan to use RetroVue with large log files, consider investing in at least 512MB memory. But having done so, debugging is fun!