Groovy Console in NetBeans IDE

I've made some progress embedding the Groovy Console in NetBeans IDE 5.5. Before going into details, here's the current result:

Before going into the remaining problems, let's first look at what it took to get to the current result. First, the good people at Groovy did the world a big favor by creating a single JAR file that includes everything needed for working with Groovy in Java. In the Groovy distribution, get embeddable/groovy-all-1.0.jar, and you're good to go. Wrap that in a library wrapper module project, attached to a module suite, add your functionality module to the suite, declare a dependency on the library wrapper module, and you can start coding for Groovy in Java. Next, you want Groovy files to be opened in a TopComponent. Readers of this blog will know how to do that (use the New File Type wizard and the New Window Component wizard, then create an implementation of the NetBeans API OpenSupport class and change the TopComponent to CloneableTopComponent).

Up to this point, everything is completely standard NetBeans API stuff, as described above. Next, you need to embed the Groovy Console in the TopComponent. That's the tricky bit and is still not perfect. Unfortunately, unlike third-party objects such as the FlashPanel, described here, the Groovy Console is not a JPanel. It is something built on top of a JFrame. So, how to embed a JFrame in a TopComponent? Not easy. The Console object is a single, encapsulated object, we can't move its contents around as we would do if we could open its sources as a JFrame in NetBeans IDE. However, there's a handy method on the Console, called Console.getFrame. That's our way in. That method returns a JFrame, from which we can get the content pane, which we then add as a Container to the TopComponent.

However, for some reason we can only get the content pane after the Groovy Console is running. I don't know why this is the case. Therefore, I call, then I get the content pane and add it to the TopComponent, and then I call Console.exit. So, when you open a Groovy file in the embedded Groovy Console, you first see a quick flashy thing, which is the Groovy Console opening and closing as a JFrame, while the content pane is added to the TopComponent. Not perfect, but workable. Hope it can be fixed somehow.

The next problem, unresolved currently, is the biggest problem. The method Console.setInputArea(JTextArea) is used to send the content of the Groovy file to the input area of the embedded console. However, once the embedded Groovy Console is opened, the sent text isn't visible! But I know it is there, somewhere in the background or hidden or something like that, because when I press Ctrl-Enter, the content of the input area is run and the result is displayed in the output area. So, if the content of my Groovy file is println "hello world", and I then open the Groovy file in the embedded Groovy Console, I don't see anything in the input area. However, when I press Ctrl-Enter, the line println "hello world" is executed. Very strange.

The final issue, currently, is related to the menu items in the Groovy Console that I am transferring to a toolbar in NetBeans IDE. (If you look in the screenshot above, I have transferred the Run, Previous, and Next items so far.) If I could simply grab the entire menu from the Groovy Console and stick it in the TopComponent, I would rather do that, but grabbing the menu seems impossible. However, the real problem is that even though I can press Ctrl-Enter successfully (i.e., the script executes with the required result), I don't know what to call from the Java code. In contrast, for example, to the "Previous" and "Next" buttons, which call Console.historyPrev and Console.historyNext respectively, there doesn't appear to be something like One would think that Console.runScript would help, but I haven't figured out how to use that, despite googling and crying and so on. I've tried playing with Robot.keyPress, suggested by Michel Graciano on the mailing list, but it hasn't worked for me so far. Therefore, this is currently another big problem for this embedded Groovy Console solution.

However, in combination with the Schliemann solution that I blogged about in the past few days, it seems clear that this embedded Groovy Console points to the possibility of there being good support for Groovy in NetBeans IDE. And, if someone can help me out with the above problems, I would be extremely thankful.

In other news. Quick! Don't miss this opportunity... here on you can now buy the NetBeans Platform book together with "Harry Potter and the Deathly Hallows (Book 7)". Can life get any better than this?


That is an interesting approach. You may want to look into the combination of Groovey Shell:

and NetBeans IPProvider APIs:


combination. It may work better.

I think NetBeans debugger uses this IOPRovider APIs to talk to the debugee. In you case it will be an in process GrooveyShell.

For additional ideas you may want to look at the:

specifically the JConsole panel and ConsoleInterface and how it interacts with BeanShell. BeanShell is an opensource project.

Posted by Sandip on March 19, 2007 at 12:11 AM PDT #

Haven't read the details, but

Posted by Ramon on March 19, 2007 at 12:15 AM PDT #

Geertjan, I kinda did what you did here a few months ago, and my solution to your problem #2 goes like this (this is the essence of the constructor of my GroovyConsoleTopComponent) : Binding bind = new Binding(); groovy.ui.Console console = new groovy.ui.Console(this.getClass().getClassLoader(),bind); try {; add(console.getFrame().getContentPane(),BorderLayout.CENTER); console.getFrame().setVisible(false); } catch (Throwable e) { e.printStackTrace(); ErrorManager.getDefault().notify(e); }

Posted by Alex Kotchnev on March 19, 2007 at 01:47 AM PDT #

Also see:

Posted by guest on March 19, 2007 at 02:05 AM PDT #

Ha, here is an even better one, puts the Console menus at the top of the component . Certainly, it would be preferrable to have some of the menus (e.g. File menu) moved to the NetBeans File menu, but still, this makes it so much more workable:
        Binding bind = new Binding();
        groovy.ui.Console console = new groovy.ui.Console(this.getClass().getClassLoader(),bind);
        try {
        } catch (Throwable e) { 

Posted by Alex Kotchnev on March 19, 2007 at 02:42 AM PDT #

Alex, you're a genius. This code is fantastic. If you know how to do this, why haven't you created a module and publicized it already? This is wonderful code.

Sandip, thanks for the pointers and being supportive of this. Very useful into. Ramon, thanks also., thanks for the link to Coyote. Do you know the status of that project, whether it works for 5.5 and whether it will work in 6.0?

Posted by Geertjan on March 19, 2007 at 02:47 AM PDT #

into = info, in my comment above

Posted by Geertjan on March 19, 2007 at 02:48 AM PDT #

By the way, all the issues I mentioned in my blog entry above are now solved. Will blog more about this tomorrow and show the result, i.e., an embedded Groovy Console in NetBeans IDE.

Posted by Geertjan on March 19, 2007 at 03:52 AM PDT #

I know you said all issues are resolved, but I've posted the source to my version that includes sucking in the ActionMap and InputMap from the console - thus all shortcuts work in the embedded console as well.

Posted by Alex Kotchnev on March 19, 2007 at 03:01 PM PDT #

hi Geertjan
Do you know of any method using which I can create a simple textArea (in the output kind window) where user can write groovy code. The groovy code is expected to interact/manipulate with the components, say, textbox, in editor window.
I don't want to use groovyConsole.

Posted by Mohit on June 22, 2011 at 09:38 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« November 2015