I've been spending some time working with the JPDA - Java Platform Debugger Architecture - and it's pretty darn cool. Using this framework, which is shipped with the basic Java SE JDK, basically allows you to write debuggers.

I hear you ask: Why on earth would you want to do this when there are so many good debuggers already? Eclipse does everything I need!

True. But what if you need one process to monitor the execution of another? And I don't mean to have interprocess communication, I mean for one process to MONITOR THE EXECUTION of the other. Sounds like a debugger to me. Why should Eclipse have all the fun?

JPDA basically consists of three parts: 1) The JVMTI, which is the JVM Tool Interface, and defines the debugging services a JVM provides; 2) The JDI, or Java Debugger Interface, which is the high-level debugger client interface; and 3) The JDWP, or Java Debug Wire Protocol which defines how socket communications between the two will be handled.

In interests of full disclosure, I've only fiddled with the JDI. As an application guy who's interested in writing a debugger, I don't need to mess with anything else. The Sun JVM already provides a rich, fully-functional implementation of both the JVMTI and the JDWP, so I really only need to use the JDI to get information about the process that is being debugged. Doing anything to enhancements or change the JVMTI or the JDWP implementations that Sun has already done would involve revising and rebuilding the VM, which is not an idea I relish. If I liked writing virtual machines, it would be a different story.

But using the JDI to build your debugger is surprisingly easy, and rather flexible. You decide whether your debugger will initiate the debuggee VM, or vice-versa, or if the debugger will attach to a previously running process, or vice-versa. Once a connection is made between the two VM's, your debugger gets an Object that represents the VM of the other process. Using this VirtualMachine object, you can then request notifications for various events, such as method entry and exit, class loading and unloading, thread start and death, etc. The events are sent by the already written JVMTI portion of the debuggee process's VM over a socket connection to your debugger and loaded into a queue. You then pull these events off the queue and process them asynchronously.

On top of that, you can do this without modifying the debugged code! You don't need its source, there's no bytecode instrumentation, no aspect weaving or special compilers, no special classloaders, no interceptors or dynamic proxies. You are hooked into the real, live VM in which the debugged code is actually running, and the same VM it will use when you're not debugging -- which is about as non-invasive as you can get.

You can read more about JPDA at http://java.sun.com/javase/technologies/core/toolsapis/jpda/