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.