The Future of Groovy
Where do you see Groovy this time next year? How about 2 years from now?
will be released before the end of this year. If all goes well and our
day jobs permit, we may release Groovy 1.0 at the beginning of Q4.
We'll see if my predictions become true! Perhaps a 1.1 release at the
end of the year will be needed to sync the JSR-241 deliverables and the
Reference Implementation. It's so hard to give an accurate roadmap for
our developments when all developers are working on their spare time,
and don't make a living out of the project. Our roadmap is a mere
estimation of what could be achieved.
With the years, Groovy will be more and more mature. Within a year
or two, anybody will be able to use Groovy for his pet projects or for
professional applications. In two years, perhaps our users will use
Groovy as a replacement to Java for their projects -- and not just a
mix of Java + Groovy. Who knows... Most IDEs will support Groovy, and
it'll be easier to develop full-blown Groovy applications.
By the way, in the following days, we should have a first version of the GroovyJ plug-in for IntelliJ IDEA.. The Eclipse plug-in
needs a little work to be usable, while at the same time, the NetBeans
guys are working on their Coyote project to support alternative JVM
In the foreseeable future, Groovy will probably include more Java 5 features
such as enums, or annotations. Annotations could be used to create
language macros that manipulate the Groovy AST (Abstract Syntax Tree)
paving the way to funky AOP features or code injection. We may also
include Generics, for statically-typed-oriented developers, but
Groovy's dynamic nature doesn't really require them, since we don't
need those ugly casts Java mandates. We can also implement some tuple
oriented operations, such as assigning multiple variables at the same
time. Support for continuations
and for mixins
would be cool too.
On the API side, I'd love to create a kind of Grail framework
(Groovy on Rails) for simple webapp development, with an MVC paradigm
and transparent and light persistence mechanism -- probably leveraging
existing APIs but with a simple Groovy wrapper. I'd like to have a
small library for SOAP services consumption. Those are the kind of
things I'd like to work on when I have some spare time.
Nothing is set in stone for Groovy 2.0, everything's open to discussion! So feel free to participate and suggest new features.
Full speed ahead! Speaking of that- what do you think Groovy's test
coverage is with respect to features? Do you have a process for unit
testing the code? How do you manage other people's code and tests or
lack of tests?
We've got over 1000
tests, from pure unit tests to more integration-geared tests. It's not
bad, but could probably be better, considering a language is such a
complex project. Some parts are not very much tested, like Groovlets,
or Ant builders
, but things are improving over time.
What's particularly interesting is that we're eating our own dog food:
most of our test cases are written in Groovy itself! How to better test
Groovy than by writing the tests in Groovy
We're improving the test coverage over time when bugs are fixed. The
process is as follows: a bug is raised in JIRA, a contributor or a
committer fixes the bug and always creates a new test case proving the
bug is indeed fixed. So each time a new feature is added, or a problem
solved, we always add a test case proving the feature is correctly
implemented or the problem really solved. That's a good thing, since we
can make sure we don't have regressions in the following releases. And
regarding contributions, we generally require our contributors to
always provide test cases with their patches.
Regarding our project infrastructure, we've got great tools at our disposal thanks to Codehaus
' own infrastructure. We've got a Continuous Integration
server which helps us know nobody broke the build by committing bad
chunks of code. And we've got some other nice tools for our project
management: such as FishEye
to view CVS activity, JIRA
our bug tracker, or Confluence
our Wiki. At Codehaus, there's a script which skins the content of
Confluence to make it look like standard HTML pages: as a result, the
whole Groovy website is user editable very easily and anybody is free
to improve the available documentation.
We're also fans of little gadgets, like Drone the IRC bot
, which can be triggered by Jeremy's "box" RSS reader to give us messages when new commits happen, JIRA issues are modified, or BeetleJuice
(our CI server) finishes a build. These tools and gadgets really
improve the feedback loop and in consequence also improve our project
practices and the overall quality of the project and reactivity of the
That's pretty ironic and funny that we have much better project
practices, tools and reactivity than most companies have in-house :-) Stelligent:
That's good news. I
really enjoy unit testing with Groovy- it's especially fun to be able
to increase one's confidence in the code base with fewer lines of code!
What are your favorite features of the language?
The MOP (Meta Object
Protocol) is certainly my favorite feature of the whole language! Uh?
But what is that MOP stuff? I've never heard of it. Is it an
undocumented feature of Groovy? Err, no, not really. If you're using
Groovy in your projects, chances are that you're using implicitly the
MOP without even knowing it.
So what is it all about? I think MOP is a term coined by the Lisp
community. Basically, it's a protocol which allows us to do method and
properties interception -- which is more familiar today thanks to the
Aspect-Oriented approaches. Basically, all Groovy classes that you
write implement that protocol: default implementations of
are provided. But you can easily override these methods to provide your
own hooks and behaviors. Thanks to MOP, you have Expandos, GroovyMBean,
Groovy builders, like the SwingBuilder, or the MarkupBuilder. It
interprets method calls and creates nodes of objects or of text, even
for non-existing methods! We can mimic BeanShell's invokeMethod()
or Ruby's method_missing()
to intercept the method calls (see
for an example). We can easily implement proxies or delegators with the
MOP. It certainly deserves better documentation on the website, like
how to intercept method calls, how to build your own builder, etc. It's
an aspect of Groovy which makes the language very powerful, but rare
are those who really know and use it.
posted on 2007-04-16 20:21 山风小子
阅读(595) 评论(0) 编辑 收藏
所属分类: Groovy & Grails