Guillaume Laforge, Groovy's project leader, was interviewed by Vanward Technologies recently. The interview is broken down into four parts:

• Why Groovy
• The JSR Venture
• Groovy's Future
• Who's Using Groovy

For Groovy's future, Mr. Laforge said (among other things):

In the foreseeable future, Groovy will probably include more Java 5 features, such as enums, or annotations. Annotations could be used to create language macros that manipulate the Groovy AST (Abstract Syntax Tree) paving the way to funky AOP features or code injection. We may also include Generics, for statically-typed-oriented developers, but Groovy's dynamic nature doesn't really require them, since we don't need those ugly casts Java mandates. We can also implement some tuple oriented operations, such as assigning multiple variables at the same time. Support for continuations and for mixins would be cool too.

On the API side, I'd love to create a kind of Grail framework (Groovy on Rails) for simple webapp development, with an MVC paradigm and transparent and light persistence mechanism -- probably leveraging existing APIs but with a simple Groovy wrapper. I'd like to have a small library for SOAP services consumption. Those are the kind of things I'd like to work on when I have some spare time.

Do you have any questions you'd like to fire at Guillaume?

I'm a shell script kinda guy. If I need something done quick and dirty, I'll write a quick unixy shell script for it.

Sometimes, when I'm about to sit down and write a new script, I think, maybe I'll try writing this in groovy (yes, I'm also a java developer).

But my first hurrdles usually are: Where's $1? How do I get the text comming in from stdin? How can I invoke another script or application and capture its output.

Now, if I were going to write a more serious, algorythmically intensive script, then maybe groovy would fit nicely.

But until groovy has access to the command line and stdin and execing other apps/scripts which is as easy as unixy shell scripting, I find that its always a little too much effort to get started with groovy.

Since Groovy has access to the whole JRE, wouldn't System.in do the trick?

Actually, you can do many of the unixy things you're looking for with groovy, although it isn't always the *best* tool for the job.

If the "quick and dirty" thing you're trying to do involves existing java libraries, such as service or model classes from your application, then groovy really shines since you have full, direct access to all of that stuff.

I often interact with web services, jms, hibernate and business service classes in quick and dirty groovy scripts. (And not-so quick-and-dirty groovy programs as well; it's not just for quick hacks).

If it's just a quick unixy thing you want to do, then you can still use groovy and mix with unix stuff.

Here are a few trivial examples to illustrate:

Process a file line-by-line and print (-p option) with a one-liner (-e option)?

groovy -p -e 'print line.toUpperCase()' some_file

Combine with unixy commands such as the unix idiomatic find/xargs?

find . -name '*.java' | xargs groovy -p -e 'println line.toUpperCase()'

In-place edits with regexp and backup files? (a la perl's -p -i -e)

find . -name '*.java' | xargs groovy -p -i.bak -e '(line =~ "private").replaceAll("protected")'

(DON'T TRY THAT ONE AT HOME!)

Work with piped-in stdin using an line iterator closure?

cat some_file | groovy -e 'l=0; System.in.readLines().each { ++l }; println l'

or

ls . | groovy -e 'l-0; System.readLines().each { ++l }; println l'

So, groovy plays pretty well with unixy stuff too.

All of the above can be done with a groovy script rather than a one-liner using -e, of course.

find . -name '*.java' | xargs groovy -p -i.bak -e '(line =~ "private").replaceAll("protected")'

This is mixed Unix shell script and groovy script.

Do we need something like that in pure groovy?

Nebojsa

But my first hurrdles usually are: Where's $1?

In a Groovy script, you can access the script parameters with the args variable: args[0] should do.

How do I get the text comming in from stdin?

With System.in, but that's not that friendly, and perhaps we'd need to add some new handy methods for that kind of task.

How can I invoke another script or application and capture its output.

Since Groovy lives on the JDK space, you can call other classes easily. And if you want to capture the output of other apps, you can do "dir".execute().text.

when can we expect to see an ide/plugin for groovy with full code completion support?

code completion is quite addictive, esp w/how complex and varied even the std java api's have become -- it is a bit of a hassle to switch to groovy and try to manually lookup all the definitions and signatures.

i'm not sure how it could be done for untyped variables but it would still be helpful for typed variables.

when can we expect to see an ide/plugin for groovy with full code completion support?code completion is quite addictive, esp w/how complex and varied even the std java api's have become -- it is a bit of a hassle to switch to groovy and try to manually lookup all the definitions and signatures.i'm not sure how it could be done for untyped variables but it would still be helpful for typed variables.

We've got the GroovyJ plugin for IntelliJ IDEA which you can download from the plugin manager. It doesn't unfortunately do code-completion yet, but that's on the roadmap. But as you can expect, code-completion for dynamic languages isn't that easy. But as you said, for typed variables, things should be easier.

Hi.
It would be great to have a groovy release with current features, free of bugs and with professional IDE(eclipse,netbeans,intellij) support.
Is it possible before new features get added?

regards

with professional IDE

jEdit I use.

Eclipse has plugin.

.V

It would be great to have a groovy release with current features, free of bugs and with professional IDE(eclipse,netbeans,intellij) support.Is it possible before new features get added?

These last few months, we've been focusing on stabilizing Groovy and fixing as many bugs as possible. Except a few improvements here and there, we didn't add any significant new features recently -- we'll keep them for Groovy 2.0 or whatever it'll be called. You should try a recent version and judge for yourself.
Regarding professional support in mainstream IDEs, it's slowly coming, but we lack some (human) resources to accomplish that titanesque task. So feel free to come and give a hand ;-)