Better debug support for Groovy-Eclipse

A short while ago, I wrote about the new debug support for GSP files inside the SpringSource Tool Suite. What I didn't describe is that this has coincided with enhanced debug support in Groovy-Eclipse.

There are a few tricks that you can do inside of Eclipse to vastly improve your debugging experience. Much of this is now automatically configured for you when you install the latest snapshot of Groovy-Eclipse, available at this update site: http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/.

Step filters

The Eclipse Java Development Tools supports the concept of step filters that enable a user to specify regular expressions of type names that should be ignored by the debugger. By this I mean that using any of the step commands (step into, step over, step out of...), the debugger falls through any types that match a filter.

This is particularly useful for stepping through Groovy MOP stack frames, including most stack frames that start org.codehaus.groovy.*, and many of the sun.reflect.* frames as well.

Groovy Eclipse now configures a reasonable set of default step-filters for you. These defaults can be viewed and edited in your Eclipse preferences:

Note that it is still possible to stop at a breakpoint set inside of a filtered type, but the next step-* command will step through to the first unfiltered type.

Show Logical Structure

At runtime, closure parameters are wrapped in groovy.lang.Reference objects. This makes for a bit of an annoyance when debugging and trying to browse variables. Take for example this simplified, but common debugging situation. You are debugging inside of a closure and you are using the variables view to explore the current value of your closure parameter:

Unfortunately as you can see, you have to dig 3 levels deep to see the contents of the list.

Again, Eclipse offers a solution. You can select the Show Logical Structure button . The result is a significantly more concise way to browse your variables:

Groovy-Eclipse has added a custom logical structure for Reference objects so that they are automatically dereferenced inside of the variables view. You can edit existing and add new logical structures in your Java Debug preferences:

Stack frame emphasis

Another common complaint about debugging Groovy code is that the extra stack frames from Groovy's MOP hides the application stack frames from view. As an exercise, try to find the application stack frames in the following code (hint: the name of the script is Script.groovy):

On second thought...don't try.  Groovy-Eclipse automatically greys-out MOP and related stack frames, making it easy to see application stack frames (without actually hiding Groovy magic):

This feature, combined with step filtering above makes stepping through Groovy code significantly more efficient.

By default, Groovy-Eclipse de-emphasizes some of the most common MOP stack frames, but this can be changed in the Eclipse preferences:

What's next?

Two of the most requested debugging features are Groovy-aware hotswapping (so that Groovy code can be edited, compiled, and loaded without needing to restart a debugging session) and a Groovy-aware Display view (so that Groovy snippets can be executed in the context of a paused application).

We've had some success with hotswapping, but more work needs to be done before it can be generally useful. Specifically, we've hit some limitations due to the class files produced by groovyc and are awaiting a fix for GROOVY-4152.

A Groovy-aware display view is something that we need to work on and I hope to have initial support for this for the 2.1.0 release in late October.

Clearly, we have work to do, but the existing debug support provides significant improvements over what was available even a few months ago.