Saturday Jul 18, 2009

Groovy and Grails related changes in trunk

In this post I'll provide you update on recent changes that happened in NetBeans. These changes will be available in 6.8 M1.

The most important thing fixed in trunk (and in 6.5.1 as well) is a regression 161176 causing "unresolved class" problems when Groovy class was referenced in Java.

Other great improvement is much better code completion for variables and parameters. As picture is worth a thousand words, compare the following two pictures.

Variable code completion in NetBeans 6.7:

Variable code completion in trunk:

There is now brand new mechanism to properly stop the process tree. It is used for Grails and seems to be much better than previous solution. It even works without admin privileges (at least on Vista). Please report any problem you find.

As there were many requests for Groovy 1.6 support it is finally available in trunk. The integration also supports AST transformations. See code completion on the next picture.

There is also couple of minor fixes and improvements. The work is not finished of course. These are just most important changes for upcoming M1. Let us know what you think.

Tuesday Jun 30, 2009

NetBeans 6.7 Released

Yesterday NetBeans 6.7 was finally released. There was no significant improvement since in Groovy area since my last post as we were in stabilization period. You can see the complete list of new features in New and Noteworthy document for 6.7.

Unfortunately there is one defect in the new Parsing API influencing integration of Groovy into Java (the opposite way is ok). This will be fixed in a patch that should be released in couple of weeks. Fix is already present in trunk build.

Wednesday May 06, 2009

NetBeans 6.7 Beta Status

As you have probably noticed the NetBeans 6.7 Beta is out. Do not expect any new features. Now we are doing stabilization fixing all the remaining bugs we know about. Here is just a plain list of important fixes.

  • Parser performance improved
  • More accurate code completion for fields
  • Removed synthetic elements from navigator
  • Navigator emphasizes element being edited
  • Stopping Grails on Windows; missing cases fixed
  • No dynamic methods derived from domain's static properties
  • Couple of other minor issues fixed

Would be great if you could test it and report any other bugs.

For those who would like to test new features I have one bad and one good message. The bad one is that no such feature can appear in main repositories until end of the May (roughly). The good one is that I already have a patch for much better code completion for parameter and variables (patch attached to issue 159463) and I'm experimenting with groovy expressions in debugger.

Thursday Apr 02, 2009

Groovy and Grails in NetBeans 6.7 M3

The last milestone of NetBeans 6.7 is out. What has been improved and fixed in Groovy and Grails area? Read below.

The biggest change is that we changed our parsing and indexing infrastructure. This should unify the code across different languages and solve several Groovy and Java integration issues. As you can imagine this is quite a big change that does not affect Groovy only. So if you are going to use M3 or daily builds please let us know any bug or incorrect behavior.

The first visible enhancement (as opposed to previous which should be ideally invisible) is the Grails 1.1 support. Now you can install and uninstall plugins while seeing the proper code completion, relevant parsing errors etc.

This should work even in case you override some of the default settings in BuildConfig.groovy. For this purpose there is Resolve Plugins action in context menu of the project. You need to execute this action only if you are using non default values and you've opened the project for the first time or you've changed the values recently. The reason why this is not done automatically, although it would be possible, is that BuildConfig.groovy is in fact a script that has to be evaluated. The IDE can't be sure what are the side effects of such script so we decide to choose the conservative way of conscious action.

Perhaps we could add a download of missing plugins as a part of this action. It would be useful after VCS checkout. What do you think? Let me know.

Another related change is overall context menu cleanup as you can see on the following picture.

Now you can also assign shortcut (although there is none by default) to Run Grails Command action. This will certainly make you very effective. I think the usage of shortcut and command dialog is even faster than the console typing.

Another important improvements were made in wizards. You can now configure your Grails installation directory directly from the project wizard. This is especially useful for new users and when using the fresh IDE installation.

Artifact (domain, controller, service, etc.) wizard was improved as well. It was cleaned up and fixed so now you can finally easily create the artifact including the package easily.

In previous releases you might run into problems while stopping the Grails application on Windows from the IDE. This was fixed with great help from Lloyd Meinholz. So running and stopping the application from the IDE should be quite comfortable now.

Also many other minor fixes were made. For example dynamic finder code completion should be now properly displayed even when the domain class is not in the default package.

Unfortunately, as always, not all interesting changes made it to M3. Several performance improvements were made just after M3. Thanks to Göran Ehrsson for valuable reports. Also field code completion is now more accurate in daily build and Groovy file navigator was improved and fixed. As this is the last milestone and stabilization period starts the daily builds should more and more stable in future. In case you are interested in the latest features and fixes and/or you want to help us you can download daily builds from the NetBeans dowload page. If you even want a couple of minutes old builds with Groovy features integrated you can get a build from continuous build server.

Monday Mar 30, 2009

Update on Grails 1.1

With upcoming NetBeans 6.7M3 or current daily build you should be able to use Grails 1.1 even with overridings in BuildConfig.groovy. I'll blog about new features and improvements soon.

On 19th March there was a great webinar Building Twitter with Grails in 40 Minutes presented by Graeme Rocher. Graeme was using TextMate so I tried to develop exactly the same thing within NetBeans IDE. With current daily build and Grails 1.1 I was able to do all the development using nothing else than browser and the IDE. Really, I didn't even need a command line!

On 25th March interesting Grails 1.1 IDE comparison was published on Grails Blog. Worth reading.

Wednesday Feb 25, 2009

Groovy and Grails in NetBeans 6.7 M2

Today NetBeans 6.7 M2 was released (yes 7.0 is now 6.7). What are the new features you can use in Groovy and Grails development? Let's have a look.

First of all there is a couple of enhancements in properties of the Grails project. Now you can disable the browser opening on project run (general category of project properties).

Another improvement in project settings allows ou to configure the JDK. You can easily configure the required JDK in libraries category.

One big improvement for Grails development is code completion for dynamic methods of domain class especially dynamic finders.

Code completion was also enhanced to work with method reference operator and safe navigation operator as you can see on the following pictures. This is usable in both Groovy and Grails of course. The next screenshot shows method dereference operator completion.

And another picture for safe navigation operator.

One feature which was missing in previous releses was the ability to run any Grails command not just those supported by the IDE integration. This was even more annoying in case you wanted to use custom script or command provided by a plugin. Now you can use context action to display the command dialog.

When invoked it displays the listing of all available commands and you can directly start typing the prefix of your command. Just by hitting enter you can run it. It would be even better and faster if the context action had a keyboard shortcut. This is not possible at the moment but planned for M3.

Other notable fixes are automatic classpath update on plugin installation (thanks Sven ;) ) and workaround for very very annoyning issue where the EDT was blocked on text selection.

I hope you'll like this.

Tuesday Feb 24, 2009

NetBeans 7.0 Renamed to 6.7

For those who haven't heard it yet the next release of NetBeans will be 6.7. So the planned M2 release coming out this week is 6.7 M2 now. The main reason mentioned in announcement follows.

To get innovation and quality improvements out to the community faster, and to have the NetBeans IDE be better aligned with the release schedules of other technologies that it supports, we have decided to concentrate on a series of smaller releases rather than the traditional two big releases per year.

You can get more info abot release plan and features in the official announcement.

Wednesday Feb 18, 2009

Grails Podcast Interview

Last week I was interviewed by Sven Haiges. Sven together with Glen Smith run the great Grails Podcast. They definitely do a good job for community. Keep up the good work guys!


Tuesday Jan 27, 2009

External Execution Support 2/2

In my last post on External Execution Support I described the basic low level API for processing streams and lines. In this post I would like to present much cooler feature for running external programs (processes) in NetBeans. The whole External Execution Support is brand new and is available in trunk and (once released) in NetBeans 7.0.

So how can this API help you with that? Let's start with simple example running the ls command.

import java.util.concurrent.Callable;
import org.netbeans.api.extexecution.ExecutionDescriptor;
import org.netbeans.api.extexecution.ExecutionService;

public class CommandExample1 {

    public Integer execute() {
        Callable<Process> processCallable = new Callable<Process>() {
            public Process call() throws IOException {
                return new ProcessBuilder("/bin/ls").start();

        ExecutionDescriptor descriptor = new ExecutionDescriptor()

        ExecutionService service = ExecutionService.newService(processCallable,
                descriptor, "ls command");

        Future<Integer> task =;        
        return task.get();

What actually happens when this code is executed? First of all the Callable returning the actual Process is created. The second structure is descriptor for UI representation of the process. The last thing you have to do is to create ExecutionService and run it. The returned Future represents the process and its return code. It might look complicated but it is highly customizable. The following picture shows the UI part provided by the API at runtime.

As you can see user will get the output of the process and can stop it while running or run it again. This is all provided by the ExecutionService. For example you don't have to create threads reading the streams. You don't have to care about synchronization of multiple threads and how to stop them when the process is finished.

Many UI configurations can be made via the ExecutionDescriptor. You can disable control buttons, define pre and post execution hooks or you can even use your custom InputOutput without UI representation to run the process on background and much more!

In ExecutionDescriptor you can also specify factory for InputProcessor and LineProcessor. This way you can easily process the output of the running process with all the features introduced in previous post. In the next sample we are running the ls command and printing the line number for each line. For process creation we use simple support provided by the External Execution Support.

import java.util.Collections;
import org.netbeans.api.extexecution.ExecutionDescriptor;
import org.netbeans.api.extexecution.ExecutionDescriptor.LineCovertorFactory;
import org.netbeans.api.extexecution.ExecutionService;
import org.netbeans.api.extexecution.ExternalProcessBuilder;
import org.netbeans.api.extexecution.print.LineConvertor;
import org.netbeans.api.extexecution.print.ConvertedLine;

public class CommandExample2 {

    public Integer execute() {
        ExternalProcessBuilder processBuilder = new ExternalProcessBuilder("/bin/ls");

        ExecutionDescriptor descriptor = new ExecutionDescriptor()

        descriptor = descriptor.outConvertorFactory(new LineConvertorFactory() {
            public LineConvertor newLineConvertor() {
                return new Numbered();

        ExecutionService service = ExecutionService.newService(processBuilder,
                descriptor, "ls command");

        Future<Integer> task =;        
        return task.get();
    private static class Numbered implements LineConvertor {
        private int number;

        List<ConvertedLine> convert(String line) {
            List<ConvertedLine> result = Collections.singletonList(
                    ConvertedLine.forText(number + ": " + line, null));
            return result;

Related output visible to a user is on the following picture.

With proper LineConvertor you can adapt the output as you need. With custom InputProcessor or LineProcessor you can process chars or lines without affecting them in any way. This is just simple usage - look at the API Javadoc to see what else you can do with the API. One thing you should note is that Process is fully abstract class so you can use the API for any process you are able to create not just OS related ones.

Let me know if you like it or when you have additional questions.

Friday Dec 19, 2008

Groovy and Grails in NetBeans 7.0 M1

Long time has passed since my last post about Groovy support. In meantime I was intensively fixing and improving the support. I fixed various bugs and enhancements and Groovy support is getting better everyday. Short list:

  • Grails installed from debian package now supported
  • Grails plugin support works behind proxy
  • Wizards properly report failed Grails operation
  • Code completion for this and super
  • Find action fixed for GSP files
  • Navigation for Domain/Controller/View improved
  • Clean supported from contextual menu
  • Run for the script is available from contextual menu
  • Proof of concept implementation of code completion for controller dynamic methods

These are just notable fixes many other small issues were resolved. If you were not using daily builds you also get all the features mentioned in my previous post.

There are more features planned for M2. We are rewriting the Groovy support to brand new Parsing API. This should bring us significant performance improvements. We also want to enhance support of code completion for dynamic methods in domain classes.

Features already pushed to trunk which unfortunately didn't make it to M1 (and thus are present in daily build only) are per project configuration of JDK for Grails and option to disable browser opening on run.

Saturday Nov 22, 2008

External Execution Support 1/2

New public API was recently introduced in NetBeans. Its name is External Execution Support and it provides the necessary support to execute external program and/or to read the output from process streams (as well as other sources of data). This post focuses on the second and less advanced part of the API usage - reading and processing data from various sources in a convenient way. This is in fact introduction of the basic API concepts. You will see more useful and advanced usages in the next post.

The module sources are located in extexecution directory and in order to use this API you have to add following fragmet into the project.xml of yor module.


One purpose of this API (that will be described in this post) is to process growing streams or files (this will became more obvious in the second part). For this reason one important thing to know is that the read cycle does not exit when the stream starts returning EOF. Lets start with an example. We suppose you have a streams as a source of data and you want to parse the lines and print them to system output.

import java.nio.charset.Charset;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import org.netbeans.api.extexecution.input.InputProcessor;
import org.netbeans.api.extexecution.input.InputProcessors;
import org.netbeans.api.extexecution.input.InputReaderTask;
import org.netbeans.api.extexecution.input.InputReader;
import org.netbeans.api.extexecution.input.InputReaders;
import org.netbeans.api.extexecution.input.LineProcessor;

public final class StreamExample1 {
    private final ExecutorService service = Executors.newCachedThreadPool();
    public void execute(InputStream stream) {
        InputReader reader = InputReaders.forStream(stream, Charset.defaultCharset());
        LineProcessor lineProcessor = new LineProcessor() {
            public void processLine(String line) {

            public void reset() {

            public void close() {
        InputProcessor inputProcessor = InputProcessors.bridge(lineProcessor);

        InputReaderTask task = InputReaderTask.newTask(reader, inputProcessor);

    public void finish() {

Now imagine what would you have to do without this API. To start a thread, read characters from the stream, parse the lines (yourself or with help of and process them. When you use the API you have it all for free - the only important part is the code saying what to do with parsed lines.

As you see from the sample the abstraction of data source is InputReader. The custom processing is provided as implementation of InputProcessor or LineProcessor depending on your needs (InputProcessor handles characters, not waiting for the whole line). InputReader and InputProcessor are then passed to factory method of InputReaderTask. InputReaderTask implements Runnable and Cancellable so you can pass it to ExecutorService, run in dedicated thread or invoke run method directly. Once the run() method of the InputReaderTask is invoked it is reading the data from the reader processing them with processor until it is cancelled.

The task can be canceled in two ways. You can either interrupt the thread or explicitly call the cancel() method. The latter is useful when you are using the third party code which reacts to interruption in undesirable way (throwing exception, immediately terminating etc.).

To make things easier API also provides several useful factory classes for InputReader, InputProcessor and LineProcessor [put javadoc links here]. If you want to print output to NetBeans' output window you have even greater posibilities. API provides four factory methods for InputProcessor and LineProcessor writing to the output window. Two of these factory methods accept LineConvertor through which you can change the printed lines and register listeners to them. Enough talking; lets see another sample. It's doing the same thing as the first one however it writes lines to the output window and whenever there is a http URL it provides a listener that will open a browser. Too complicated? I don't think so - see it for yourself.

import java.nio.charset.Charset;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import org.netbeans.api.extexecution.input.InputProcessors;
import org.netbeans.api.extexecution.input.InputReaderTask;
import org.netbeans.api.extexecution.input.InputReader;
import org.netbeans.api.extexecution.input.InputReaders;
import org.netbeans.api.extexecution.input.LineProcessor;
import org.netbeans.api.extexecution.print.LineConvertors;

public final class StreamExample2 {
    private final ExecutorService service = Executors.newCachedThreadPool();
    public void execute(InputStream stream, InputOutput io) {
        InputReader reader = InputReaders.forStream(stream, Charset.defaultCharset());
        LineProcessor lineProcessor = LineProcessors.printing(io, false,

        InputReaderTask task = InputReaderTask.newTask(reader,

    public void finish() {

Although you can pass only single covertor to printing support and only single processor to task you can use multiple convertors and processors via proxying implementation available as helper factory methods InputProcessors.proxy(InputProcessor...) and LineConvertors.proxy(LineConvertor...).

The API is generally usable, but its main purpose is to be used for continuous processing of stream and files (yes, files are supported as well). In this blogpost I presented just the first (less interesting part) and I introduced some key interfaces. If you would like to use it to support external process execution wait with that for the next post which will introduce the part of the API designed specifically for this.

Wednesday Oct 15, 2008

NetBeans and Groovy Enhancements

As promised in previous post several enhancements for Groovy were pushed to development version of NetBeans.

The major change is that the plugin now supports (and uses) Groovy 1.5.7 which contains several important bugfixes. Other areas improved in code completion:

  • More accurate code completion on dot
  • Return types displayed in code completion are now accurate (including generics)
  • Removed duplicate entries
  • Correctly displayed method access level
  • Field icons correspond to modifiers
The next thing in code completion area I would like to address is better support for Grails controllers.

Saturday Oct 04, 2008

Groovy Code Completion in NetBeans

There were significant improvements in code completion for Groovy in NetBeans during the last few days. The code completion is now more accurate and reliable.

It provides the correct suggestions for methods and fields of statically typed variables, literals and collections. The correct code completion is now provided for these types inside if and for statements and other places. Also the simple type inference now takes place when using the latest development builds.

You can also see some visual enhancements such as better representation of method access level and return types.

Certainly there are areas to improve, such as completion of unparsable code fragments and extended type inference. Try the improvements for yourself. If you want to help us make it better, report the code fragment which provides the wrong results to issuezilla (component groovy). We can easily turn such fragment into a test cases and fix them.

This is just the beginning. More enhancements coming soon.


Petr is a NetBeans software engineer responsible for the Groovy & Grails support.


« August 2016