I've spent some time this weekend looking over the Grails
codebase. After a truly gigantic checkout (Grails bundles production
JARs for all the libraries it integrates) and after swimming through a
substantial, single-project sea of source files, I think I'm starting
to follow it (though a tour by someone familiar with Grails internals
would be nice). But there's something else I've learned in the
There's really no reason this couldn't use Ruby just as easily as Groovy.
look at some really dumb numbers. Grails, as it turns out, is actually
over 2/3 Java code, unlike Rails which is 100% Ruby. Grails contains
around 436 Java source files for about 54kloc of code and 273 Groovy
source files for about 23kloc of code. So Java outnumbers Groovy by a
2:1 ratio. And yes, Java's probably more verbose than Groovy in most
cases. But my point stands, and I'll back it up with more...
there's the libraries. The Grails binary release weighs in at a
whopping 26MB compressed and 49MB uncompressed (*wow*). But 31MB of
that is third-party libraries completely independent of Groovy, things
like Hibernate, XFire, Quartz, Apache Commons, and so on. Almost all of
which (or perhaps all of which) are pure Java code. So the ratio is
even more heavily toward Java.
These numbers and my exploration
of the code base lead me to a surprising conclusion: Grails is not a
"Groovy on Rails" by any means. It's a large number of popular,
well-established Java libraries stitched together mostly by Java code
with a thin layer at the front (20kloc is not much) of Groovy code for
end-users to see and work with. And I guarantee you it's not the Groovy
part that's most interesting here. Hell, you could write that part in
Java if you followed enough "convention over configuration", and you
certainly could write it in Ruby.
I decided to do this
exploration after realizing there's nothing about Ruby or JRuby that
couldn't be used to wire a bunch of Java libraries together--indeed,
that's one of the biggest selling points of JRuby, the fact that you
can write plain old Ruby code but call Java libraries almost seamlessly
(with day-by-day improving integration points and performance numbers).
So why not take Grails and do a port to Ruby? Groovy code isn't far off
from Ruby in many ways, and everything you can do in Groovy you can do
in Ruby (plus more), so the port should be pretty straightforward,
Then I find out that Grails is mostly Java code. And
instead of being annoyed or repulsed by this revelation, I was
intrigued. Why not make Grails work with Ruby as well? And really, why
not make it work with any scripting language? Why limit that
nicely-integrated back end by forcing everyone to use Groovy,
regardless of preference? Have we learned nothing from a decade of
"100% Pure Java"?
So I propose the following.
believe it would be possible to completely isolate Grails' tastier bits
from Groovy. I don't claim it would be easy, but Grails is fairly well
interfacified, injectificated, and abstractilicious, so making that
dividing line clear and bold is certainly possible (and heck, that's
the point of dependency injection and component frameworks anyway,
isn't it?). Really, I could start implementing a few of those
interfaces right now with Ruby code, but that's not the right approach.
value is not in Groovy, but in the clean integration of established
libraries behind the "Convention Over Configuration" mantra. There's
nothing specifically Groovy (or Ruby) about that religion, and there's
nothing Groovy does in Grails that another JVM language couldn't do
just as easily. This is *truth*. And Grails would benefit tremendously
by expanding to other languages. Being tied to Groovy alone will hold
it back (just as a framework tied to any one language will be held
back, Ruby included).
- I also believe that if the Grails project
doesn't make an official effort in this direction, others are likely to
take up that mantle themselves. Though the debates will forever rage
about which JVM dynlang should carry us into the future, the same facts
that have guided programming for half a century still apply today: No
one language will be enough to carry us forward; no languages will
survive indefinitely; and the language you'll use in ten years you've
probably not even heard of yet. Did anyone expect Java to be the most
widely-used, widely-deployed language ten years ago? Well today, it is.
It won't always be.
- There's also a very interesting angle here
for language enthusiasts. Nobody doubts that the Java platform is
officially becoming multi-lingual, possibly a complete reversal from
years past. But there are going to be growing pains here, and we're
already feeling them on some projects at Sun. We have this wonderful
platform with all these wonderful languages...and they all do things
differently. We have a first stab at official "Scripting" support in
JSR-223, but it only defines the integration point from Java to the
language in question...only partially defining the integration points
for those languages calling back to Java (a tricky problem) and
defining *nothing* related to making those languages interoperate with
each other. Again, Java becomes the integration point, and the
bottleneck (as in "how do you pass a dynamic-typed object from one
language to another by sending it through a statically typed
language?"). The very exercise of making Grails (or any other
framework) work equally well across multiple user-facing language
interfaces will require better interoperability and more
clearly-defined integration points for dynamic and static languages on
- The Phobos
guys at Sun are already tackling many of these same problems while
JSR-223 languages (notably, Ruby). So anyone taking on the Grails
effort would certainly not be alone, and there are some damn smart
engineers at Sun interested in tackling these very same problems.
I guess in the end it's a question of how visionary we all can be. Can
the Grails team envision a future for Grails that doesn't require the
use of Groovy? Are you (and am I) as a non-Groovy developer willing to
help them get there? And in the end, isn't this what thought leaders on
a multi-lingual platform are supposed to be doing?
enough of the inflammatory bull-baiting. I dare you to tell me why I'm
wrong here. Even better, I dare you to look into it yourself. 75kloc of
code, only a third of it Groovy. Established libraries you're sure to
have used at some point. Clean integration, following the principals
inspired and proven by Rails.
But fronted with your language of choice.
Make it so.
附：朝花夕拾——Groovy & Grails
posted on 2007-05-01 00:45 山风小子
阅读(531) 评论(0) 编辑 收藏
所属分类: Groovy & Grails