Why Groovy?

There probably aren't too many people in the Java world who haven't heard of Groovy. And for those that have taken a closer look at Groovy, they are probably familiar with the name Guillaume Laforge. As the defacto Guru of Groovy, Guillaume has guided the project through the ambitious JSR migration as well as setting the tone and the climate for the Groovy team.

Read on as Guillaume shares his experiences as Groovy's governor, his thoughts on Groovy's future and why you should consider giving it a spin.

Stelligent: How did you get involved with Groovy? What made you decide to participate so heavily?

Guillaume: In mid-2003, I was working on a very interesting project at a small startup. We were building a webapp generation engine that can dynamically create a whole application by just defining its data model.

It's somewhat in the same vein as the MDA approaches we have today, but the way we did it was different than the classical UML-modeling + templating technique.

In OpenAge (Open Application Generation Engine), you design your data model in a Swing "designer": you tell the entities you want to manipulate, and their properties and relationships. OpenAge creates a "metamodel" representing your business model, and you deploy it on a webapp functioning as the kernel of the system. At runtime, this kernel interprets the metamodel you've created, and you can directly use the dynamically generated webapp.

But that's not all, you have a wealth of UI widgets you can use to represent and manipulate the attributes of your entities. You have a strong user/profile/role rights management system. And there is also a powerful querying system to search your entire business model, capable of following all the relationships and applying complex criteria. What got me interested in scripting languages was the fact our users could create their own UI widgets in the "designer" application, and have them deployed on the "kernel" webapp, so that the final application could have customized UI widgets. And typically, I thought scripting languages could fill in that gap: at that time, the UI widgets were mere Java classes compiled and deployed once and for all, and we could have used Groovy (or any other language) to create those widgets. That's how I got interested in Groovy: I was looking for the right tool for the job.

Why Groovy, rather than another language? Well, there was quite a lot of hype around Groovy back in 2003, when it saw the light of day. And it seemed to be a very promising language, with some innovative ideas, and some familiar features taken from wonderful other great scripting and/or dynamic languages like Python or Ruby. Jython was stalled, as well as JRuby. BeanShell was too limited to my taste (not opened to non-Java-esque features), and I had not done enough JavaScript to want to use Rhino -- though it may have been a good alternative. I then looked at Groovy a little closer, tried it, and discovered some bugs. Being of a curious mind and Groovy being an Open Source project, I had a look at the source code, and I wrote some patches fixing the bugs I had encountered. Later, I provided a few features I wanted Groovy to have, like better i18n behavior (Groovy wasn't very good with non-ASCII charsets) or new handy methods to add to the standard Java classes.

After a while, James Strachan asked me if I wanted to become a member of the team and a committer on the project. I gladly accepted. Finally, over time, I got more responsibilities, and became the de facto project lead and official "Project Manager".

Stelligent: A lot of people choose to avoid using scripting languages for various reasons- why do you think so? What can we do as a community to embrace them?

Guillaume: First of all, let me say that not all projects can benefit from scripting languages. I see three main use cases for scripting languages on the JVM -- the stress on the JVM is important here:

• as an embedded component of a Java/J2EE application, to help write and customize business rules, or other moving parts of your application
  
• as a shell scripting language on the command-line, like Ruby or Python, for any data crunching or file management task, or for experimenting with new unknown Java APIs
  
• as a full-blown replacement to Java for small to mid-sized projects, or for testing purposes

The biggest market for scripting languages on the JVM, in my opinion, is in the embedded use cases. And only projects with constantly evolving business rules, UI widgets, or complicated customizable templates can leverage and benefit from those languages. For most cases, webapps are pretty CRUD-oriented, and don't really require a higher level of dynamic-ness.

If developers are under that dynamic-ness constraint, they won't really have other alternatives than using a scripting language. I think they need to get more acquainted with those tools, even if, so far, they managed to cope with a business rules engine like Drools (you can write rules in Groovy), or template languages like Velocity or FreeMarker. They need to choose the right tool for the job, and Groovy may well be overkill! With time to play and experiment with Groovy, people might get addicted to it, and start using it more often.

With Java 6 and the inclusion of the javax.script/JSR-223 API, it'll be much more common and easier to use scripting languages. I strongly believe that the situation will evolve over time, and we'll see more usages of scripting languages, and more Groovy-fied applications.

Moreover, books will also arrive on the shelves to help flatten the learning curve. There are at least two books in the works currently: I'm currently writing one for O'Reilly with Russel Winder and another one is being written for Manning.

Stelligent: Yeah, I'm aware of a few others as well! When you order fries from a fast food restaurant in France, are they called French Fries?

Guillaume: Hehe, no! We simply call them "frites"!

Stelligent: What are your duties with respect to the Groovy project? Who are the other players in the project?

Guillaume: I think I wear several caps at the same time! I'm doing user support as much as I can. I recruit new committers when I notice some contributors have provided us with great and useful patches. I'm also a mere developer as well and a member of the JSR-241 Expert Group standardizing Groovy. I tend to organize the work we're doing on the code base, to prioritize the features we need to implement, or the bugs that need a fix. From time to time, I also solve some infrastructure issues, like configuring a Continuous Integration server, etc. That's quite fun and a real pleasure to touch each and every part or aspect of the project!

But nothing would be possible without my teammates. James Strachan is spending less time on Groovy than at its debut, but we've taken the torch and often consult him to have a glimpse of his "Groovy vision", or to sort out crucial language decisions. My close lieutenants are Jeremy Rayner, Jochen Theodorou, and Christian Stein. Jeremy's our grammar lead and Antlr expert. He's also worked on various parts of the project, like improving the error messages, building groovy/groovyc Ant tasks, reducing the project build time, etc. Jochen is our new Swiss-Army-knife developer. He's the one you can thank for the various compile-time checks added in our latest release, as well as the implementation of interface or abstract classes support in Groovy. He's probably the best human debugger I've come across so far. Christian, who recently joined the team, is doing a lot of work and refactoring of our web-related features: Groovlets, Templates, and so on.

There are a few other committers who also make great things, like Franck Rasolo who's working hard on producing a promising IntelliJ plug-in, Kim Pilho who fixed some nasty bugs, Russel Winder who converted the code base to use a more recent version of ASM, Dierk König who introduced method interception mechanisms or fixed bugs. I can't name everybody, but I think I've pictured our main committers.

Stelligent: So what is a Quarter Pounder with Cheese really called in France?

Guillaume: I believe it's called a "Royal Cheeseburger"!

原文地址：http://www.stelligent.com/content/articles/article.php?topicId=81&pageName=Why+Groovy%3F
附：Groovy轻松入门——Grails实战之GORM篇