The Future of Groovy

Stelligent: Where do you see Groovy this time next year? How about 2 years from now?

Guillaume: Hopefully, Groovy 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 languages.

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.

Stelligent: That's exciting! 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?

Guillaume: 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 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 team.

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?

Guillaume: 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

invokeMethod(), get/setProperty() 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

http://article.gmane.org/gmane.comp.lang.groovy.user/4253 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.


原文地址：http://www.stelligent.com/content/articles/article.php?topicId=81&pageName=The+Future+of+Groovy
附：Groovy輕松入門——Grails實戰之GORM篇