W.H Auden, the British born, US settled poet, who many regard as one of the greatest writers of the twentieth century, once said that ‘civilizations should be measured by the degree of diversity attained and the degree of unity retained.’

His words though questioning long-held assumptions could equally apply to the world of computer programming – diversity is returning in the world of programming languages.

Fourteen years ago, Sun introduced Java, which arrived in such a blaze of light that the mantra ‘write once, run anywhere’ was based on the fact that Java’s runtime can be installed everywhere from desktop PCs and mobile phones to web servers and mainframes.

Java usage soared and thanks to the backing of industry giants such as IBM and Oracle it looked to be the only language a developer would ever need – though Microsoft later countered the claim  by developing its own runtime platform, called .NET, able to run several languages, which has also been very successful.

Java though remains the most popular programming language in the business world running as it does on an estimated 7 billion electronic devices around the world but other languages are growing. One factor is the web and others are efficiency and productivity – compelling words in hard times.

The idea that one language is good enough for most tasks has been shown to be wrong – some Java developers weren’t really happy using it because most were doing web development in a language that was clearly unsuited to it.

Hence the recent trend towards dynamically typed languages. And of the most popular is Groovy a ‘glue’ that offers a flexible Java-like syntax that most developers can learn quickly.

As the official Groovy Project Manager, Guillaume Laforge spends his time bringing a versatile and agile environment to the masses and was the first to initiate the seed of Grails, the Groovy & Spring web framework.

A frequent conference speaker presenting Groovy and Grails (formerly Groovy on rails)  at JavaOne, SpringOne, QCon, the Sun TechDays, and JavaPolis he co-authored Groovy in Action along with Dierk König.

He has worked in partnership with the Google App Engine Java team before the official launch of the new and while doing so created Gaelyk, a lightweight toolkit for developing applications written in Groovy on the Google App Engine.

Before this he founded G2One, which was bought by SpringSource in late 2008, and taking the role of VP Technology.  Guillaume has also worked for OCTO Technology, a consultancy focusing on architecture and agile methodologies and while there developed new offerings around Groovy and Grails for its clients.

RM:

Was the aim with Groovy to simplify the life of Java developers by giving features that were not available in Java? And where did the name come from?

GL:

Back in 2003, after suffering with Java and loving the features available in dynamic languages like Ruby, Python and Smalltalk, lots of questions arose of the form of, ‘Wouldn’t it be ‘groovy’ if Java had this or that feature and you could replace said feature with closures, properties, meta-programming capabilities, relaxed Java syntax?’ and more.

When it came to choosing a name, it was obvious that a new language with all those great features would have to be called ‘Groovy.’

So it’s not really a reference to counter culture, nor about jazz, but just about the dream of having a language close enough to Java, but more powerful and expressive.

That’s how we came by the name and yes you’re right about simplifying the life of Java developers.  It’s exactly how Groovy started. Java is a really great language, but you can’t really evolve it on your own, so its progress is rather slow and you may feel a bit frustrated when you don’t find feature X or Y in it.

Whereas with Groovy, we have a pretty pragmatic approach to the evolution of the language, adding new features we liked in other languages such as Smalltalk, Python or Ruby when it makes sense.

RM:

What are the chief differences between Groovy and other dynamic languages such as Ruby, Python and Perl?

GL:

The key differentiator is the seamless integration with the Java platform underneath. It’s something no other languages provide, even alternative languages for the JVM (Java Virtual Machine), or at least not up to the level that Groovy does.

First of all, the grammar of the language is derived from the Java 5 grammar, so any Java developer is also a Groovy developer in the sense that the basic syntax is already something he would know by heart. But obviously Groovy provides various syntax sugar elements beyond the Java grammar. The nice aspect of this close relationship is that the learning curve for a Java developer is really minimal.

Even at the level of the APIs, aspects such as the object orientation and the security model are all just what you would be accustomed to with Java. There’s really no impedance mismatch between Groovy and Java. That’s why lots of projects integrate Groovy, or why companies adopt the Grails web framework.

RM:

How do you decide the evolution of the language?

GL:

We’re following the rules of the Codehaus Manifesto as the project is hosted there. (Editor’s note: Codehaus has since closed, but the Codehause manifesto can be found on Github.)

So I’m trying not to be a too strict a despot, and try to engage the Groovy development community to discuss new ideas for language features or new innovative APIs, to continuously improve the language.

Once a consensus is reached on whether a certain feature is needed, and that we have a good picture of how it’ll be implemented and will be used, we commit to implementing it, releasing it early in betas of the language so our users can try it out.

We’re really listening very much to our user base; to be sure we’re adding the features they need for their everyday work.

RM:

As you know Guy Steele who co-authored Java is working on developing a language better than his co-creation, a language that will have high productivity and an improvement large enough for people to find it worthwhile to go to the effort to learn it. Do you think Groovy has refined Java so much that you’ve done much of Guy’s work for him?

GL:

Ah well, certainly, yes. Groovy is really used a lot these days, in various contexts, enterprises, etc. And the benefits in terms of productivity are obvious.

So, yes, we’ve done our best to refine Java, with our own tastes, our
own ideas, to make developers lives easier!

RM:

With Java growing in popularity as a platform what we can expect will emerge in the coming years as language implementers experiment with the JVM?

GL:

Predicting the future is not an easy game. It’s always difficult to guess in advance what the next big evolutions will be. But it’s nice to see we’re paving the road towards better support for dynamic languages on the JVM, for instance, thanks to the new byte code instructions that are being introduced in JDK 7 – the so-called ‘invokeDynamic’ instructions.

Also languages that speak multi-core are going to be more and more important in the future, to leverage our parallel CPUs.

These days, we are revisiting a lot of old research concepts around those topics, and hopefully, this will materialize into new languages features which will also help us be more productive in these areas.

RM:

Can you tell me a little about Grails and is it a solid example of what can be done with Groovy?

GL:

Grails is a highly productive web development stack. More than a mere Web framework, it provides an advanced integration of the best-of-breed open source software (OSS) components, such as Spring and Hibernate, to provide a very nice experience for developers using it, while also taking care of various other aspects like the project build, the persistence, a rich view layer and an extensible plugin system. Clearly, Grails leverages Groovy heavily, to bring productivity boosts to developers at every step of the project. Grails’ choice of Groovy and all the other components it uses makes it a very compelling platform for high-traffic and complex applications.

RM:

Groovy exists less to win than to affect the issues brought up by the mainstream of course but can you see a time when developers will only use Groovy, and not Java?

GL:

Groovy’s always been pretty humble and never claimed it’d replace Java any day. On the contrary, it’s been designed to be Java’s dynamic friend, a language to complement Java when Java falls short.

We’re seeing more and more companies using Groovy in combination with
Java, rather than as a replacement for Java itself. That being said, applications built with Grails, for example, are usually built fully in Groovy, rather than using any Java, but that’s also the programming model and all the productivity boosts the platform provides that encourage developers to use Groovy as much as possible.

RM:

What has been your greatest challenge in developing Groovy and how did you work it?

GL:

The two main challenges have been about a total seamless interoperability and integration with Java, as well as performance.

The former has always been part of our design goals, so we’ve always done our best to take care of all the bugs and keep up with the pace of Java itself (for instance when Java 5 introduced annotations, enums, and generics).

For the latter, we made sure that Groovy would be the fastest dynamic language available (both in and outside of the JVM). We used various techniques, such as ‘call site caches’ and related techniques. We’re also very enthusiastic and optimistic about the upcoming JSR-292 ‘invoke dynamic’ byte code instructions coming soon into the Java Virtual Machine, which should bring very significant performance boosts.

RM:

Do you feel a sense of competition with Scala or other Java-like languages?

GL:

These days, the alternative languages which are the most visible or hyped are clearly Groovy, Scala, JRuby and Clojure.

We’re all looking for increasing our mind-share in the Java development community, so, yes, in a way; we’re competing with each other.

But each has got its sweet spot, for certain use cases, for different populations, etc. So there’s room for everybody.

But also what’s nice with competition is that it encourages everybody to always work harder to make an even more compelling platform for our users!

RM:

The Groovy on rails project has found its way into commercial applications, most notably LinkedIn, is it about to convert the enterprise crowd?

GL:

Indeed, we made a lot of progress those past months or even years, and here at SpringSource, we’re clearly seeing a lot more companies developing new internal and public-facing applications with Grails.

We’re also publishing some case studies on our website of our customers and their testimonials on why they decided to use Grails for their applications.

RM:

Closure Support is listed as Groovy’s first feature on the Groovy site but as you know Java doesn’t have this feature. The debate has been rumbling on for some years now. What is your argument for Java supporting closures natively?

GL:

Interestingly, at Devoxx, it was just announced that a form of simple closures will eventually find its way into Java 7

It was really unexpected at that point since the year before Sun had announced closures would be out of the equation. Closures really help to write better algorithms, implement new control abstraction, and even help bring some functional programming flavour into object-oriented languages. Closures are a really powerful tool in a language tool belt. That’s why Groovy’s implemented them since day one.

Now, we’ll have to see the exact proposal for closures in Java, to see how practical and easy to use they are. Particularly, statically-typed languages, with all their constraints (generics, checked exceptions, etc), can potentially make closures more cumbersome to use than they are in more dynamic languages. I’m very much looking forward to seeing the final proposal for Java.

RM:

What’s the winning argument for users mix and matching Groovy-Grails with traditional JavaEE techniques? And what’s the advantage of choosing Groovy over languages such as Ruby?

GL:

As we often say, use the best tool for the job. Groovy simplifies lots of painful tasks in Java, such as handling XML, simplifying access to a database, and more.

But the key selling points of Groovy and Grails is that these technologies have been developed with the Java developer in mind, so as they can quickly get up to speed and productive with them, and furthermore, in such a way as to protect the investment made in the training, platform, licenses, and more.

A Grails application is just a WAR to deploy on a standard application server. Your IT production team doesn’t even need to know it’s been built with a different framework than usual, so all the infrastructure and procedures that we’ve put in place over the years still apply.

With Groovy, being designed a Java’s cousin, Java developers feel directly at home with writing code in Groovy. Actually, a Java developer is already a Groovy developer without really knowing it. And they don’t suffer from a steep learning curve, so the adoption is pretty progressive and smooth.

RM:

If Sun was to approach you to go and work in their Fortress team would you consider it?

GL:

No, Fortress is not a language that appeals to me, as it’s really not in my area of expertise and interest.

But for people with a high interest in high performance calculation, or with a FORTRAN background, this is certainly a project to keep an eye on.