Groovy stacktrace folding

Posted on by Peter Gromov

When you look at a typical Groovy stack trace, you usually see something like this:

This is not terribly helpful, since there are only three lines from the actual source code. Everything else refers to Groovy’s internals. From now on, though, reading Groovy stack traces will be much easier:

Comments below can no longer be edited.

19 Responses to Groovy stacktrace folding

  1. Stefan A. says:

    March 17, 2010

    Thanks a lot for that. Groovy stacktraces are no fun without that.

  2. Yarin says:

    March 17, 2010

    Great new feature!

    Any thoughts about doing it for Spring based (AOP) applications?
    When running Spring AOP applications, the stack trace is full of aspect wrappers and proxies that pollute the stack trace and makes reading it a pain.

  3. Guillaume Laforge says:

    March 17, 2010

    Very nice! Good idea!
    Perhaps you could also filter the org.jetbrains.* lines as well?

  4. Peter Gromov says:

    March 17, 2010


    No. It was a stack trace precisely from the IDEA project, so it’s definitely the code I’d like to see when developing IDEA. And I don’t know of any place when the org.jetbrains.* stuff really gets in the way. Do you?

  5. Peter Niederwieser says:

    March 17, 2010

    Very nice. How do you decide whether a line should be displayed (or not)?

  6. Peter Gromov says:

    March 17, 2010

    Now it’s just hardcoded, and it’s all Java reflection, org.codehaus.groovy.* and groovy.* (except for DefaultGroovyMethods). It should probably be configurable, though I don’t yet imagine a UI for it.

  7. Ronny Løvtangen says:

    March 17, 2010

    This is brilliant!
    A UI to configure this would be nice (like YourKit Java Profiler has).
    I would love to be able to filter other stuff as well, like Spring and Struts.

  8. Glen says:

    March 17, 2010

    Looks nice. I’d love to see something like this for La Clojure too. Clojure stack traces are even uglier than groovy.

  9. Mike Cantrell says:

    March 17, 2010

    Love the idea. If you were to develop a UI, I think it would be nice to have a whitelist as well as a blacklist for folding.

    For instance, maybe I’m only interested in:


    And the rest is folded.

  10. Hamlet D'Arcy says:

    March 18, 2010

    Peter, the UI for which packages to filter can be the exact same list as which packages to _not_ step into. The settings panel already has this list. I opened a bug for exactly this a few months ago.

    Great improvement gang, thanks!

  11. Peter Gromov says:

    March 18, 2010

    Hamlet, not exactly. The current not-to-step-into-list doesn’t allow to step into DefaultGroovyMethods while not stepping to everything else in groovy.*. While I’m not so sure whether I need to step into that code, I definitely want to see it in the stack traces.

    The idea of combining the two lists is very attractive, although maybe too dare, but the stepping filters are actually a JVM feature and have a very restricted format, which AFAIK doesn’t allow for exclusions like DGM. It also doesn’t support filtering for specific methods in the class, (e.g. in the java.lang.reflect.Method we filter out only the invoke() method). So, it’s not that simple.

  12. Stephan Anft says:

    March 18, 2010

    Very nice. I would love to see this feature in “normal” Java code, too. For example a button in the run console that filters out all stack trace lines referring to classes from external libraries.

  13. Geoffrey De Smet says:

    March 18, 2010

    This could be usefull in spring stacktraces too: to hide all the AOP proxy and reflection stuff under a + sign.

  14. Jim Bethancourt says:

    April 22, 2010

    +1 for Geoffrey’s suggestion on filtering the AOP/Proxy reflection stacktraces listed by Spring. Great idea!

  15. Dan Sheehan says:

    April 23, 2010

    +1 to AOP filtering
    +1 to user configurable via UI

  16. Peter Gromov says:

    May 7, 2010

    To everyone who asked. ConsoleFolding plugin with configuration UI available at

  17. Juan Hernandez says:

    May 19, 2010

    Nice feature.

    +1 to user configurable via UI

    I could include then …
    org.jboss.el.util.ReflectionUtil.* (or org.jboss.el.util.ReflectionUtil.invokeMethod)

  18. Laird Dornin says:

    August 2, 2010

    Why doesnt Groovy just edit its own stack traces?

    java.lang.Throwable {
    public java.lang.StackTraceElement[] getStackTrace();
    public void setStackTrace(java.lang.StackTraceElement[]);

  19. Peter Gromov says:

    August 3, 2010


    Actually, it sort of does. If you run a script and there’s an exception, all the lines which correspond to *.java code will be removed. I guess the assumption was that the only Java code executed in a Groovy program is Groovy internals, which is often not true.


Subscribe for updates