New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Dynamic Language IDEs: News From Groovy-Eclipse

| by Mirko Stocker on Dec 18, 2008. Estimated reading time: 5 minutes |

This news item belongs to our series about IDEs for dynamic languages. The first one covered Ruby IDEs, other parts can be found through the DynamicLanguageIDEs tag.

Now that SpringSource has acquired the company behind Groovy and Grails, Groovy will rise in popularity and thus be more attractive to Java developers.

We talked to James Ervin, the lead of the Groovy Eclipse project, and asked what people currently are working on:

Right now there is me and a couple of other interested people making contributions to the plugin. Guillaume La Forge made me the project lead so that I could update the official release of the plugin to include fixes for issues that have been in the pipeline for some time. I am currently focused on stability, simplification, regular releases and tackling some of the top issues on our JIRA site. For instance, I am trying to finish off using the joint compilation ability in the Groovy compiler (the ability to compile both Java and Groovy source files by delegating to Javac when necessary). This should remove some of the headaches involved with the additional bin-groovy target directory and the issues with cross dependencies between code written in Groovy and in Java. Michael Klenk and his group did some wonderful work cutting a version of Groovy Eclipse that supports refactoring. After my current task is complete, integrating their work is my #1 priority.

The Groovy-Eclipse already contains a Groovy implementation and doesn't need an external one: 

Groovy Eclipse comes with an embedded Groovy runtime library that is split off as its own Eclipse plugin (or in OSGi parlance, bundle). It is included for several reasons as I will get into now. First off, an embedded runtime allows us the opportunity to flex our muscles and begin to write parts of the plugin in Groovy. As has been said, there is nothing like 'eat your own dog food.' I like the original expression better, its more apropo in you will, but this is a family friendly setting. Secondly, including an embedded runtime library allows us to obviously allow the user to skip the step of having to install the groovy runtime before they can do anything. Finally, and this is actually a weakness, we use the embedded groovy runtime to both introspect and compile the code in your projects. The last point is a sore point with me and is something that I covered in my roadmap for Groovy Eclipse.

Taking a look at the roadmap, we can see several interesting positions:

  • [...] provide at least a basic level of support for Grails development. I know that there has been some work on providing Grails support, but I know it could only be of the very basic sort and there is so much in Grails that screams for IDE support.
  • [...] enable Eclipse Plugin Development using the Groovy language. This is really more of a personal desire, I think that Grails support or any of the other points I have listed would affect far more people. Still it would be nice to be able to do more and more Groovy Eclipse work in Groovy, right? I think so. As part of this effort we could try to leverage and improve Groovy support for EMF
  • [...] better integration of the groovy compiler with Eclipse JDT support. I saw an example in the Scala Eclipse plugin where the project has the Eclipse Java nature added to the project, but the Java Builder was not added. This allows the Scala plugin to provide the scala tools to build the class files. I think that something like this should be done for Groovy Eclipse, especially since the groovy compiler will now compile java as well.

Other implementers of Groovy IDEs are certainly struggling with similar problems, is there any collaboration going on?

I have been in on some discussions on the GROCIDE project, this is also high on my priority list for Groovy Eclipse. Our number one problem is that we do not have resources (i.e. man hours, particularly full time hours) for the project, but there are a lot of things that the individual IDE support tools could share. This is something we need to be involved with especially since there are good people doing good work on both the IntelliJ and NetBeans tooling support for Groovy.

I would like to conclude with the following. I added the following the the main page for the Groovy Eclipse project at Codehaus:

"The purpose of the Groovy Eclipse plugin is to promote the Groovy platform and ecosystem as a viable and productive development environment for Java developers working in the Eclipse SDK."

That surmises my goal as best as I can imagine. Today, at least in North America, the vast majority of Java development is done on the Eclipse SDK. I want for Groovy to thrive, but to do so we have got to get not just a good, but a great, Groovy plugin for Eclipse!

Regarding the refactorings James mentioned, we talked to Michael Klenk:

We started with the implementation of the refactoring Extract Method to get into the business. After the first tiny steps we started to implement the other refactorings Inline Method, Rename of methods, variables, fields and classes. We also provided a source code formatter and a hierarchy view to support the developer at his daily work.

To what extent are these refactorings you mentioned better than simply doing—say renaming—by hand?

At the first look search and replace seems to be a good approach to start, but the names in a program are always in a context, which is very important to understand. Imagine writing two methods that each declare a locale variable with the exact same name. With a simple search and replace you have to decide manually which occurrences should be renamed.

Another example how intelligent a refactoring should be: Create an interface which declares an abstract method. This method is now implemented in several classes. If you would like to rename this method, a check of all classes in the inheritance hierarchy is needed to find all positions in the code which should be changed.

The analysis of the abstract syntax tree of the Groovy code, allows us to collect all relevant information we need.

The list is alredy quite impressive, which versions contain these features?

We integrated all of our refactorings in the development trunk of the Groovy-Eclipse project. A stable version of this plugin will be released soon, so that the refactorings will be available to all developers. We hope that many users will use these first refactorings and return feedback to improve them. Another cool feature we are considering to implement is cross language refactoring between Java and Groovy.

Groovy-Eclipse's official website and the dedicated Groovy-Eclipse refactoring site.

This news item is part of our ongoing series about dynamic language IDEs. The other parts can be found under the DynamicLanguageIDEs tag at InfoQ. 

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

ActiveState Komodo kicks buttocks by Evgeny Zislis

Would love to see a review about "Komodo IDE", it's one of the best IDEs for dynamic languages out there - and for some reason no one is talking about it much. The commercial version has all the bells and whistles, like Git/Bzr/Hg/Perforce support, local and remote debuggers, etc. But the "Komodo Edit" version is FREE, and it's really great.

It has all the beauty of TextMate with snippets and such, and the functionality of Eclipse with built-in debuggers (even remote debugger for perl/python/tcl, no ruby unfortunately), code assist, built-in command (in your favorite language) consoles, and whatnot. And naturally all the dynamic languages you can think of, including JavaScript (w/Venkman debugger built-in), XUL, Python, Perl, Tcl, Ruby (with Rails support), and a bunch more that I never even knew existed. The addon system (just like in Firefox) is nice and fills the holes missing in the core offering.

Maybe because it's written on Mozilla XUL instead of Eclipse is the reason no one mentions it and why there are relatively so few addons for it?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you