Cross language dependencies

Full support for any kind of dependency between .java and .groovy files is supported.

Generics Checking

Since JDT can now understand groovy source (to a degree), it applies some generics checking to the groovy code and will report correct warnings that groovyc would not normally show:

Incremental compilation

Changes made to either .java or .groovy files will result in an incremental compilation of the containing project.  Even if the dependencies are in a different language, the impact of the change will correctly propagate.

AST transforms

Projects may exploit AST transforms that are accessible on the project classpath. Transforms like @Singleton that are defined by groovy are immediately accessible due to the groovy libraries being on every groovy project classpath. To exploit transforms provided by third parties, the jars containing the transform implementation must be added to the project classpath prior to usage. As a temporary feature (still under evaluation) in this version, transforms defined in .java files may be exploited in the same project they are defined, although on changing the transform it may be necessary to do a full build of the project to pick up the change.

Compiler level switching

The Groovy-Eclipse plugin M1 ships with both the 1.7-beta2 and 1.6.5 versions of the groovy compiler. Currently, the only way to switch between the two versions is outside of Eclipse. Here is how:

1. Shut down Eclipse
2. Go to eclipse/configuration/org.eclipse.equinox.simpleconfigurator
3. Make a backup copy of bundles.info
4. Open bundles.info in a text editor
5. Find the line for org.codehaus.groovy_1.7.0 and delete
6. Restart eclipse

To re-enable the 1.7 compiler, simply reinstate the backed up copy of bundles.info.

@Grab annotation

Basic support for Grape and the Grab annotation is included, but the code using the annotation may show a compile error (due to a missing dependency), however it will run as a groovy script:

Wizards

The wizards available mimic their Java counterparts.

New Groovy Project Wizard

The new Groovy project wizard allows you to create an Eclipse project pre-configured with Groovy support:

It supports all of the options available for Java projects:

New Groovy Class Wizard

This wizard creates a new Groovy class, with many of the same options available for the Java Class creation wizard:

New Groovy Test Case Wizard

This wizard assists you in creating a new Groovy JUnit 3 or JUnit 4 test case:

Convert Legacy projects

On startup, you are reminded to convert any legacy groovy projects in your workspace:

If you can decide to permanently dismiss this dialog box, you can still do the conversion from the preference pages:

Groovy Editor

As much as possible, we try to provide the same kind of behavior in the Groovy editor as you would expect in the Java editor. By default, the editor uses a different set of colors from the Java editor in order to emphasize the difference between the two languages. However, if you prefer standard Java syntax coloring, you can select it on the following preference page:

Additionally, the Groovy editor provides the following capabilities.

Early error indication and reconciling

Errors are highlighted as you type. This functionality is provided by hooking into JDT's reconciling capability:

An additional benefit of reconciling means that content assist proposals that come from files with unsaved changes will appear where expected. In the following example, the Shape class the definition of the numberOfSides property has not been saved to disk yet, but it appears in the content assist proposals list of the ShapesTest class:

Content assist

Inferencing content assist has been available since earlier versions of the Groovy-Eclipse plugin. We are continuing to improve on this. For M1, we have focused on reliability and availability of content assist. For M2, we will focus on completeness of results. And for the final release, we will work on some performance tuning.

In following example, notice that there are two levels of inferencing happening. The editor correctly determines that someObject is an int numberOfSides is an int:

And now, the inferencing engine is able to determine that the type of someObject is now a String:

Navigation

Typing F3, or CTRL-click (CMD-click on Macs) will navigate to the definition of a reference. Navigation hooks into the same inferencing engine being used for content assist. So, pressing F3 on the following:

will open an editor on the declaration:

You can also notice reconciling at work here because the Shape.groovy has not yet been saved since the numberOfSides property has been added.

Search

We have introduced some basic search functionality for M1. Currently, search will be able to locate method, field, and type references if they are explicitly typed. Local variable references cannot be found yet. This is a feature that is of primary importance for M2 and will be significantly improved in the coming snapshot builds.

Again, notice the affect of reconciling in that the search results view contains both references to numberOfSides even though the text has not yet been written to disk.

JUnit Monospace font

There is an option in the Groovy Preferences page to show the JUnit results pane in monospace font:

This is helpful for viewing the results of Spock tests. With monospace font, the results pane is much easier to read:

than it is without:

Launching

There are three launch options for your Groovy files and projects:

Groovy Application

This is similar to launching Java applications. A main method of a Groovy or Java class is launched and you are provided with options similar to launching a standard Java application:

Actually, this launch configuration is so similar to the Java Application launch configuration that it may disappear in future versions of the plugin. Every launchable class file generated from a Groovy script is a valid Java program. And so, all Groovy scripts should be launchable as a Java application in Eclipse. This is currently possible, but needs some further testing before we can safely remove the Groovy application launch configuration.

Groovy Script

This launch configuration launches a *.groovy file as a script. It is identical to running the groovy command from the command line. This launch configuration does not require class files to execute. Only *.groovy files are necessary. As an example of this,it is possible to explicitly remove a Groovy file from the build:

And from here, it is still possible to execute a groovy script:

This launch configuration allows the use of the @Grab annotation since scripts do not need to be compilable before they are executed as Groovy Scripts.

Groovy Shell

This launch configuration allows you to run a groovy shell in the console view. When run from a particular project, all class files in the classpath of the project are available from the groovy prompt. For example, it is possible to run a Groovy shell and execute code in the following manner:

Note that there is a bug on windows where the groovy> prompt appears twice on each line. See GRECLIPSE-434.

Breakpoints and debugging

The Groovy-Eclipse plugin allows you to set breakpoints on any statement in a Groovy file, including inside closures, by clicking in the gutter bar next to the line where you want the breakpoint to occur:

When launched in debug mode as a Groovy Application or Groovy Script, execution will break when a breakpoint is reached:

When there is ambiguity as to where the breakpoint should be placed, the debugger stops at both locations. As in the previous example, the debugger will stop at the definition of the closure c as well as whenever closure c is invoked.

Debugging will even work if there is no class file available for the particular script being debugged. However, there is an extra step on how the debugger finds the source code for the script. When the debugger stops inside a script that does not have a corresponding class file, you will see this kind of editor:

Click on the Edit Source Lookup Path... button and you will see the following dialog:

Click on Add... and the following dialog appears:

Choose Workspace Folder and select the source folder that contains your Groovy script. The end result should look something like this:

Now, the debugger knows how to find source code for scripts without class files. Please note that in future versions of Groovy-Eclipse, we will include functionality to perform this source lookup automatically.

Viewing variables

Once a breakpoint is reached, (as in Java code) you can evaluate variables:

This lets you inspect the current state of the program and even look at the Groovy meta-classes and closures accessible in the current scope.

Runtime evaluation of Groovy code

It is also possible to evaluate code snippets from the display view while in a Groovy scope:

Java syntax is required for evaluating code snippets. What this means is that explicit casting of Groovy objects will be necessary for local variables and dynamically typed references.

Conditional breakpoints

The Groovy debugging facility supports conditional breakpoints (Java syntax required). To create a conditional breakpoint, right click on the breakpoint definition and select Breakpoint Properties...:

The breakpoint properties dialog appears. Select Enable Condition and enter the condition to break at (again, only Java syntax is available, so it will be necessary to explicitly cast all variable references):

And now the debugger will stop at the defined location only when the condition is evaluated to true!

Indentation & Formatting

The Groovy editor will automatically indent poorly indented code on a paste. So, this:

Becomes this:

Quick suffix switching

It is simple to convert from a .java file to a .groovy file and back using the context menu:

Organize imports

The Groovy editor supports automatic organizing of imports (CTRL-Shift-O or CMD-Shift-O). Or you can set your project to automatically organize on save through the project properties page:

Note that only Remove unused imports, format on save, and indent on save are respected in Groovy editors. All other cleanup options are ignored.