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.
