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
How did you get involved with Groovy? What made you decide to participate so heavily?
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 +
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
was stalled, as well as JRuby
-- 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
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?
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
- 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
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
, 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
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
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.
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?
Hehe, no! We simply call them "frites"!
What are your duties with respect to the Groovy project? Who are the other players in the project?
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.
So what is a Quarter Pounder with Cheese
really called in France?
I believe it's called a "Royal Cheeseburger"!
posted on 2007-04-16 20:10 山风小子
阅读(724) 评论(0) 编辑 收藏
所属分类: Groovy & Grails