Screaming Penguin - Source Does Matter

Many modern IDEs have all sorts of support for running applications, even servers, in process with the IDE; and then debugging from there. It's good to also be aware, however, that you can debug *external* processes pretty easily as well. This is made possible by the Java Platform Debugger Architecture.

Basically, modern JVMs have a set of profiling interfaces (one for the front end, and one for the back end), and a protocol, that work together to enable external debugging.

The JVM has a native interface implementation, based on JVMTI, on the back end, and the front end debugging application uses a Java interface based on JDI. The protocol that enables communication between the two is JDWP. Using this setup debuggers can easily connect to remote Java processes, and perform their typical beloved duties.

To demonstrate the concepts, let's step through an example using GWT-Maven to launch a GWT project, and then debug that project from Eclipse.

To begin, an external Java process needs to be running, and that process must have been configured to pass the -Xdebug and -Xrunjdwp options to the JVM at startup (optionally the newer-agentlib:jdwp option is preferable on Java 5.0 and above VMs).

The exact options used for this example, which are passed automatically via GWT-Maven using the "gwt:debug" goal, are as follows:

-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,address=3408,suspend=y

More detail about all of the options is available in the JPDA documentation.

Basically, in this case, I am telling the GWTShell to start and wait for a debugger to connect before continuing. In a shell session this looks like the following (notice the process stopped, and is waiting for a connection on port 3408):

Once the process is waiting for a debugger to connect, the stage is set. The next thing to do is simply to connect with a debugger to the port shown - this is where Eclipse comes in.

To connect with Eclipse you must use the "Run dialog," and select new "Remote Java Application." From there simply specify a name for the project, and the port as shown (this screen shot shows port 1941 from a previous run, in this case it would need to be changed to 3408 to connect to the GWTShell process started above):

With that, all the pieces are in place, the JVM is running as the back end, and the IDE has connected as the front end. In this example the GWTShell continues along and launches the application, and from there you can click around to exercise the Java code.

As with any typical debugging you can use breakpoints and step into and out of the code, and inspect the state as you go. Though the screen shot here is small, you get the idea with the blue breakpoint dot and green highlighted code line:

All in all the process is very easy once you understand the roles of the components. Though this example used GWT, and GWT-Maven (something where external debugging comes in ultra handy), keep in mind that these concepts can be applied to any external Java process (a Tomcat server, a JBoss server, a Swing app, even an Applet - with a few caveats).