Groovy bridges the scripting and the enterprise Java worlds

Scripting / agile / dynamic languages for Java have been around for some time. However they seem to be getting more attention lately, because of the growing popularity of languages like Ruby and frameworks like Ruby On Rails. So the Java community looks hungry for an alternative to Ruby On Rails and a scripting language that it can easily adopt using Java knowledge. Enter Groovy and Grails.

In this interview, we speak to Guillaume Laforge, the project manager for Groovy and the initiator of Grails. Guillaume sounds very excited about the features of the Groovy language and he also feels that Grails which was originally “Groovy On Rails” is the ROR alternative for Java that the community has been looking for.

Do share your thoughts on scripting and groovy using the comments form on the last page of this interview.

IndicThreads >> Welcome to IndicThreads. Could you introduce yourself?

Guillaume Laforge >> Hello dear IndicThreads readers! My name is Guillaume Laforge. I’m the Groovy Project Manager, and one of the core committers on the project. I’ve been participating in the development of the project for already over 2 years. In my “real life” – professional life that is – I’m a Software Architect at OCTO Technology (http://www.octo.com), a French-based IT consulting company dedicated to architecture.

IndicThreads >> The confusion with scripting languages really begins with the word scripting. Very few Java developers are sure of what is scripting. To add to it, these languages are also referred to as agile or dynamic. Could you help us understand what are scripting languages and what’s the need?

Guillaume Laforge >> It’s tough to give definitions for these words! Because almost everybody has its own definition of what scripting, dynamic or agile mean. So I’ll give you my own definitions instead – some might disagree with this classification.

“Everybody has an own definition of what scripting, dynamic or agile means…”

Usually, scripting languages refer to languages which are interpreted, but not compiled. They are mostly used and live on the command-line, in shell environments, like bash. Those languages are often used to “script” some live applications, objects or components, to manipulate them programmatically, and potentially interactively.
Agile is often used to refer to language that offer some syntax sugar or simplified APIs to do some common and somewhat complex tasks in an easier way, giving you more productivity gains than a general-purpose language. The idea is to help you do complex tasks easily, either by providing simple APIs or by giving you an expressive syntax.

Groovy Team: Left To Right: Guillaume Laforge, Jochen Theodorou, Dierk Koenig, Jeremy Rayner, John Wilson and James Strachan

Then comes the term “dynamic”… it conveys two distinct meanings, but it is often used mistakenly interchangeably for those two meanings. Languages that are “dynamic” are often called so because they support “dynamic typing”, or weak typing: you can omit type information when passing parameters or defining new variables or fields. It is different than say in Java which is strongly typed and requires you to prefix every parameter, or instance with a type upon declaration. Talking about dynamic languages this is a bit misleading; we should say dynamically-typed languages instead, to be more accurate.

The second meaning of “dynamic” is more interesting in that is refers to languages that offer some kind of dynamic features in the form of meta-programming capabilities. Then you might ask what is meta-programming? It’s like programming, expanding, extending, manipulating the language constructs themselves. For example: adding new methods on an object at runtime, intercept non-existent method calls, injecting or changing the behavior of an object. We also speak about the MOP: the Meta-Object Protocol, which represents all the manipulations you can do on your language and its constructs.

If we take those definitions for granted – and I know some may disagree with my own definitions – Groovy is a scripting language because it can be interpreted at runtime, despite it can also be pre-compiled as normal Java classes are (in the form of .class files full of bytecode instructions). But Groovy is also a dynamic language in both senses of the term: it can be dynamically typed (though it also supports static typing), and it also offers a MOP, a way to add and manipulate language constructs to extend its capabilities.

As to what’s the need of those families of languages, it really depends on your use case. In a lot of cases, you won’t need such a language, and you’d probably better use a full-blown statically-typed language with a nice IDE to work with. But scripting languages come in handy for prototyping spikes, for small to mid-sized projects where the expressivity matters more, or for integrating some customized logic to be interpreted or changed at runtime for bigger enterprise applications.

IndicThreads >> Great! That would have been a big help to many readers. Now coming to Groovy, who’s the target audience for Groovy? Java developers or developers from the scripting world wanting to use the power of Java through a language more suited to their tastes?

Guillaume Laforge >> The main target audience is the Java developer crowd. Groovy’s been conceived with those Java developers in mind. That’s why its syntax is quite close to Java’s syntax. We wanted to make a language that developers could use to glue components together, to write quick shell-like scripts to do some administrative tasks, to give means to add some expressivity to your business rules you could embed in your Java application.

“Groovy somehow bridges two worlds: the scripting world and the enterprise Java world…”

But I’ve been told quite recently that Groovy is even taught to students in some universities as a first or second language. And we also hope we’ll attract to the Java platform some scripting fans like PHP developers. Groovy somehow bridges two worlds: the scripting world and the enterprise Java world.

“Groovy’s main target audience is the Java developer crowd…”

IndicThreads >> Will Groovy one day become the standard scripting language for Java, which I will get as part of the Java SE / EE download? Is there some Groovy support in Java 6, Mustang?

Guillaume Laforge >> Java 6, also known as “Mustang”, will incorporate JSR-223, “Scripting for the JavaTM Platform”. The current Reference Implementation of JSR-223 provides integration with Groovy, so if you’re using it, you can right away, even on JDK 1.4 or 5.0. You’ll have to use a newer version of Groovy though, because currently, it’s an old beta version which is provided.

“Java 6 “Mustang”, will incorporate JSR-223, “Scripting for the JavaTM Platform”…”

Mustang betas integrate a slightly modified version of JSR-223 which only integrates Rhino, the JavaScript engine from Mozilla. Unfortunately, as far as I know, they don’t integrate Groovy at all. So we’ll certainly have to create our own script engine for Java 6, but be sure we’ll be ready before Java 6 hits the streets.

IndicThreads >> X vs Y always makes for good reading. Can I interest you in a Groovy vs Jython comparison?

Guillaume Laforge >> To be frank, I’m not really interested in making such comparisons. There are many reasons for that. First of all, I don’t know the other languages for the JVM well enough to be able to make fair comparisons. I also don’t want to spread false assertions because of my biased views. And one last reason is I don’t want to “fight” with others on the tune “mine is better than yours”, because it’s a waste of time, and because we’re on the same boat! We all want good scripting languages to embed in our applications, or to write standalone applications!

“We all want good scripting languages to embed in our applications, or to write standalone applications…”

If you’ve been programming in Python for several years, you’ll be at home with Jython, so I guess there’s no compelling reason to choose Groovy if your teammates know Python well. Same thing for JRuby if you already know Ruby well. If you prefer a pure Java syntax with possible weak typing, BeanShell is perfect too. If you also want a Java-like syntax, but with the possibility to use powerful APIs and to be able to do advanced class manipulations with the Groovy Meta-Object Protocol, then Groovy might be a better fit.

“There’s no compelling reason to choose Groovy (over Jython) if your teammates know Python well…”

Each language has its pros and cons, and I can’t really recommend one myself, though my preference would go to Groovy obviously because of its expressivity and its advanced features. It really depends on your use case!

IndicThreads >> How do you decide what goes into groovy? Has Groovy tried to fix any irritants in the Java language? Also have you adopted any ideas from established languages like Python and Ruby?

Guillaume Laforge >> Currently, not much goes into Groovy, because in the following months, before the first release candidate, we’ll be in “feature-freeze” mode. So we won’t add anything new, except potential improvements or bug fixes. Groovy decided to provide a few wrapper classes around common and widely-used APIs. So we’ve got handy classes for dealing with JDBC, for creating Swing GUI interfaces, or for manipulating Ant tasks easily. But what’s clear is that we don’t want to create our own versions of APIs, we’re just offering some syntax sugar to make tedious things simple – like handling connection or stream handling.

“What irritated us with Java was all the boilerplate code we had to write…”

“With (Groovy) closures and ad hoc methods, we can safely forget about those repeating and boring boilerplate code snippets and focus on the main task at hand…”

What irritated us with Java was all the boilerplate code we had to write for iterating over collections for instance, for handling resources properly. With the help of closures and ad hoc methods, we can safely forget about those repeating and boring boilerplate code snippets and focus on the main task at hand. Groovy lets you be more productive in those situations, and let you avoid making some common mistakes like forgetting to close a stream, and so on.

“Once you’re accustomed with the concept of closures, you’re hooked and you wonder how Java doesn’t already support this feature!…”

We’ve borrowed some ideas from well-known scripting languages. The biggest feature is certainly the closures, which are coming from languages like SmallTalk and Ruby. Once you’re accustomed with the concept of closures, you’re hooked and you wonder how Java doesn’t already support this feature!

IndicThreads >> “Closure Support” is listed as Groovy’s first feature on the Groovy site. Could you tell us what are closures, maybe with an example?

Guillaume Laforge >> Closures are just reusable and assignable blocks of code. That’s a concept which unfortunately doesn’t exist in Java today. If I had only one feature request for Java, that would be to support closures natively!

“Closures are just reusable and assignable blocks of code…”

In Groovy, a closure just looks like a block of statements delimited with curly braces. So for example, the following line is a closure:

{ println "hello" }

But you can also assign this closure to a variable:

def helloClosure = { println “hello” }

Then you can call this closure as if it were a normal method:

helloClosure() // and it’ll print hello

You can pass parameters to a closure:

def printer = { msg -> println “your message is: $msg” }

Then you can call and reuse this printer closure:

printer( “hello” )
printer( “Groovy!” )

But let’s see a more useful example now. Say you have a list of things you want to filter:

def myNumbers = [1, 2, 3, 4, 5]
def criteria = { it > 3 } // ‘it’ is an implicit parameter
def result = myNumbers.findAll( criteria )

You can pass a criteria to the findAll() method on list to find all the numbers greater than 3. You can use anonymous closures too:

def result = myNumbers.findAll { it > 3 }

In Java, you have a few lines of boilerplate code to do such a simple thing as filtering a collection! In Groovy, it can be a single line.

Closures give you more expressivity to your code by allowing you to reuse snippets of code to manipulate collections and many other things.

IndicThreads >> Currently there are several scripting languages floating around, each with its set of experts saying that scripting language X is the future. That only makes developers unsure, and they end up staying away from all the languages. What is Groovy’s USP?

Guillaume Laforge >> I think Groovy’s biggest selling point is its MOP (its Meta-Object Protocol). That’s not the most widely known aspect of Groovy, but in conjunction with closures, you can do really cool things. From these two things, we’ve built the concept of “builders”.

“Groovy’s biggest selling point is its MOP (its Meta-Object Protocol)…”

Builders let you build complex structures very easily. Let’s see that with some examples, since a few lines of code are often worth thousand words:

A markup builder:

new MarkupBuilder().html {
    head { title "Groovy in Action" }
    body {
        ['red', 'green', 'blue'].each {
            p(style:"color:$it", "Groovy rocks!")
        }
    }
}

You can mix and match markup code as well as normal Groovy code, and it’ll print:

    Groovy in Action

Groovy rocks!

Groovy rocks!

Groovy rocks!

We’ve got a Swing builder that lets you create GUIs:

def theMap = [color: "green", object: "pencil"]
def swing = new SwingBuilder()
def frame = swing.frame(
    title: 'A Groovy Swing',
    location: [240,240],
    defaultCloseOperation:WindowConstants.EXIT_ON_CLOSE) {
    panel {
        for (entry in theMap) {
            label(text: entry.key)
            textField(text: entry.value)

        }
        button(text: 'About', actionPerformed: {
            def pane = swing.optionPane(message: 'SwingBuilder')
            def dialog = pane.createDialog(null, 'About')
            dialog.show()

        })
        button(text:'Quit', actionPerformed:{ System.exit(0) })
    }
}
frame.pack()
frame.show()

And you’ll get a quick GUI like the following screenshot shows:

More generally, the MOP lets you manipulate the language itself to let you build your own language structures, or your own “Domain Specific Language”. Only “dynamic” languages can do that kind of things. Simple scripting languages can’t do that. That’s where Groovy particularly shines.

IndicThreads >> So if Groovy is easier to use than Java and yet has the power of Java, do you think that it can someday take over from Java? Are there any drawbacks which will stop Groovy from making inroads into Java’s market?

Guillaume Laforge >> I don’t think Groovy will take over Java. It’s not our goal anyway. Groovy and Java are made to cooperate together.

As Dierk Koenig (Founder of Canoo WebTest and Groovy developer) says: “Groovy is Java’s best friend”.
It’s not a competition. One of the main reasons why Groovy is there today is because we wanted to “embed” a scripting language in Java applications. Groovy is a tool to have in your toolbox if you have to externalize some programmatic configuration, or business logic. But of course, Groovy can be used to build full-blown applications too, if you so desire.

I don’t think Groovy will take over Java. Groovy and Java are meant to cooperate .

I hope that in the next few years, we’ll see more opportunities to mix and match languages on the JVM. Certain things are easier to do with Groovy than with Java. And since you can compile your Groovy classes to standard java bytecode, choose the best language for the task!

With the frenzy around AJAX or Ruby on Rails, we’re all aware of the powerful capabilities of scripting or dynamic languages. And you can bet we’ll see more usage of them in the future.

BeanShell and Groovy have a Java-like syntax which makes learning them much easier

Regarding drawbacks, well, there’s always the learning curve. Jython or JRuby have got a “foreign” syntax, when compared with Java, but BeanShell and Groovy have a Java-like syntax which makes learning them much easier. The other important drawback I see is about tool support, and especially IDE support. Current plugins mostly just support syntax highlighting, compilation, running. But they don’t offer the nice features available in standard Java IDEs.

IndicThreads >> Can you tell us where the popular Java IDEs stand as regards Groovy support?

Guillaume Laforge >> We’ve got some plugins for the most used IDEs: IntelliJ IDEA, Eclipse and NetBeans – plus some syntax files for text editors like TextPad, Jedit and others. However, the support is still somewhat basic: you have syntax highlighting, compilation, running, testing, but it lacks more advanced IDE features. With time, we’ll get there, of course, but we need some contributors experienced with writing good plugins for those IDEs. We’ll certainly focus more on the tools support when we’re done with the first final release of Groovy.

IndicThreads >> Are any frameworks being built around Groovy or is it being integrated into any of the well known Java frameworks?

Guillaume Laforge >> There are already plenty of frameworks embedding Groovy. For example, there’s the RIFE framework which allows you to define your elements (controllers and actions in RIFE speak) and your site structure in Groovy. NanoContainer also supports Groovy. The eXo Platform CMS makes heavy use of Groovy, as well as XWiki, the second-generation wiki engine.

“There are already plenty of frameworks embedding Groovy…”

But perhaps the more compelling integration is with the Spring framework. In Spring 2.0, scripting finds its way into the core (previously it was just in the sandbox). You can inject Groovy beans just as normal Java beans, transparently! Groovy becoming more mature, it’s integrated in quite a lot of frameworks and applications. Some critical applications are already in production with Groovy inside.

“In Spring 2.0 you can inject Groovy beans just as normal Java beans, transparently!”

IndicThreads >> Ruby On Rails is getting a lot of attention and the Java community is hungry for a Java alternative. Is Grails the thing?

Guillaume Laforge >> I sincerely think Grails is “the thing”, as you say. First of all, Groovy has the feel of Java – with its Java-like syntax – and gives Grails dynamic capabilities that Java counterparts can’t have. Grails builds upon excellent components such as Spring, Hibernate and SiteMesh, to create a full-blown environment for developing applications quickly, and it will let you focus on the business tasks rather than wasting time with some boilerplate code our long and tedious configuration files that could’ve been avoided with a good “convention over configuration” paradigm as popularized by Rails.

“I sincerely think Grails is “the thing”…”

With Grails, you write simple Groovy beans for your domain classes, and they are persisted to the database automatically. Groovy decorates those beans to give them some additional dynamic methods such as save(), delete() or findByXxxx() without making the beans implement or extend any base class, thus leaving your objects free of any dependencies upon the framework itself.

You can write your services and have automatic injection of dependent services by just declaring the service you rely on. It’s also very easy to build controllers and actions with injection of services, and also with scaffolded actions like list/create/edit/etc for your CRUD-oriented apps.Grails is really a very promising framework that will truly increase your productivity.

“Grails is really a very promising framework that will truly increase your productivity…”

IndicThreads >> How suited is Groovy for enterprise development? Are you planning any replacements for JSP, Servlets and EJBs?

Guillaume Laforge >> Critical applications are already deployed in production spiced up with some Groovy scripts and classes. For example: a fortune 500 insurance company in the USA has deployed such an application, a London-based financial institution too, some high-traffic websites do use Groovy too.

We’re not planning on replacing anything. We prefer building upon something and bringing more agility in the process of using this or that technology. To add a Groovy-feel if you wish! There are very good components or libraries, and it would be a waste of time to try and make something new. We prefer looking from the shoulder of the giants.

The sole replacement there could be is Grails’ GSP: Groovy Server Pages. It’s Grails own version of JSPs. And it goes beyond JSPs in terms of functionality. First by letting you write scriptlets in Groovy, and also because it supports some special Grails dynamic tag libraries, but can still use JSP tag libs too.

IndicThreads >> Thanks Guillaume for this groovy interview. Readers can keep up with Guillaume through his blog at glaforge.free.fr/weblog.

Guillaume Laforge >> That’s been a pleasure to answer this interview! Thanks a lot.
2006 should be a Groovy year, with the release of our final version of Groovy, and the first releases of Grails, our web application framework.
Some books will also hit the shelves in a few months. Dierk Koenig, Andrew Glover are finishing the last chapters of “Groovy in Action”, for Manning.
And as shown on my blog, there will be an excellent coverage of Groovy at JavaOne 2006!

(little correction, the best URL for my blog is this one: http://glaforge.free.fr/blog/groovy that’s the one with Groovy content)

Related:
>> BEA to support scripting languages
>> Java apps can incorporate scripting language programs
>> Introduction To Groovy @ The IndicThreads Pune Java Meet
>> I’m a big fan of scripting as much as possible