We have just released Groovy-Eclipse 2.1.0.RC1. This release includes a number of exciting new features and fixes for over 40 jira issues. For this milestone release, we have focussed on the Eclipse 3.6 stream of Groovy-Eclipse, and are continuing to maintain the 3.5 stream. You can download the milestone releases here:
In this release, we have focussed on the inferencing engine and content assist.
Groovy-Eclipse 2.1.0.RC1 includes Groovy 1.7.5 and is installable on Eclipse 3.5.2, 3.6.0, and 3.6.1.
Update site zips
Zipped versions of the update sites are available at:
Generics-aware type inferencing
The Groovy-Eclipse inferencing engine is now aware of generic types. For example, the type of the loop variable in a for loop is inferred from the type of the collection expression:
And, of course, the editor will notify you when you are using a loop variable incorrectly:
There are a couple of pieces not yet implemented in this area, that we are planning post 2.1.0. First, inferencing of the type of the closure variable inside of
DefaultGroovyMethods is not available yet. For example:
In this situation, the type of
it is Integer and the
abs() method is valid, but it will be underlined in the Groovy editor.
Also, type inferencing for maps and lists is currently simple. The static type of the first element of the list or map is looked at. If the type can be determined, then it is used, otherwise
Object is used.
Generics-aware hover support
Similarly, code hovers now display the generics information of the value being selected:
Improved content assist
We have made a few improvements to content assist to make it easier for users. In addition to the improved type inferencing described above, which will provide better proposals for lists and maps, we have worked on a better sorting algorithm for proposals.
In prior versions of Groovy-Eclipse, the most commonly used content assist proposals such as local variables often got lost amidst rarely used proposals such as Default Groovy Methods and type proposals. Now, we have reworked our relevance algorithm and we ensure that local variables are above, instance methods and fields are next, and type proposals are always last.
As you can see in the screenshot above, the ordering is non-static fields, static fields, non-static methods, static methods, default groovy methods, and finally types.
Extension point for proposal filtering and sorting
For Groovy DSL implementors, we have provided a new extension point for Groovy-Eclipse that allows third-party plugins to provide additional sorting and filtering for Groovy content assist. For more information, see the org.codehaus.groovy.eclipse.codeassist.completion.completionProposalFilter extension point in the org.codehaus.groovy.eclipse.codeassist.completion plugin.
Using named parameters in content assist
There is a new option in the Groovy preferences page for enabling the insertion of named arguments for method calls during content assist. This is perhaps not such an important feature for end-users, but it is useful for DSL implementors who would like to force certain kinds of methods to be always completed with named parameters. There is new API available to create named-parameter method proposals.
You can toggle using named parameters on the Groovy preferences page:
And when this preference is switched on, inserting a method proposal will automatically insert parameter names:
The 2.1.0 final release is scheduled for a week from now to coincide with the 2.5.0 release of the SpringSource Tool Suite before SpringOne 2GX in October. Because this version is a release candidate, only critical bug fixes will be made between now and the final release.
We appreciate community support and feedback. If you wish to join the discussion about Groovy-Eclipse then please sign up for the mailing list. For any issues you have (or enhancements you'd like to see), please raise them in our issue tracker.