The JSR Venture

Stelligent: Ok good, I feel better now. Back to Groovy-as anyone who's kept an eye on Groovy over the last year or so would know, the syntax changed with the new JSR parsers. Why was that done? Can you elaborate on the decisions that were made?

Guillaume: It's hard to summarize all the decisions and motivations that lead us to introduce syntax changes. But the general idea and main goal was to bring more predictability and readability to your Groovy programs. And let me say that in fact, the changes aren't very big usually, and are easy to fix, thanks to the documentation we've set up on the website to ease the transition.

Let's take an example: requiring def when defining variables or methods when no type is specified. In certain cases, it was difficult to know whether we were defining a new variable shadowing an existing one, or reusing the existing one. It was hard to know by looking at the source code what the user intended: Groovy could misunderstand the original intent and create a local variable instead of reusing a variable already present in an outer scope. Using def makes the intent clearer: we're defining a new variable, and we can't mistake it as an assignment.

Another example: using @Property to create class properties with automatically generated getters and setters. Before this annotation, getters and setters were generated if no particular visibility was set. But it wasn't that clear whether your fields would or wouldn't have getters/setters generated. Now, with a particular annotation, we know the intent of the developer, and it is much clearer when reading others' code. The source code must be easily parsable both by the developer and by the parser. But we often preferred making the developer's task easier, rather than amplifying our work on the parser front. I think we're on the right track to make Groovy code crystal clear.

Stelligent: I didn't find the migration process all that difficult, myself. There weren't any big surprises either. What's left to do before Groovy is considered 1.0?

Guillaume: There are two things to consider: on one hand, we have the Groovy binary release that will be the Reference Implementation (RI) of JSR-241, and on the other hand, we have the Test Compatibility Kit (TCK) and the Groovy Language Specifications (GLS). Those are three artifacts that must be produced by the JSR process and the Groovy development team. I think it is going to take more time to have the TCK and GLS than to have a final release for the RI.

For me, the 1.0 release of Groovy will be the RI release, so I'll concentrate on explaining what's left to do for that deliverable, letting aside the GLS and TCK. It may also happen that while finalizing the GLS and TCK, the Groovy version matching the spec will be 1.1. Time will tell.

So back to the items on our to-do list towards the final release...

We need to properly implement the return/break/continue semantics in closures. The current behavior is a bit inconsistent, and is closer to the standard method semantics. But closures are specific beasts that need particular handling (should return return from the closure like a mere Java method, or should it return from the method calling the closure? etc.)

Some changes are in order for the builders, perhaps with a particular with Builder notation, which will allow us to distinguish standard code to builder code. It's needed because we've hit limitations in the builders, especially the markup builder which cannot properly create namespace-aware XML, or with tags containing hyphens, because the colon and the hyphen characters aren't valid Java identifier characters. And also because we can't always discern what is a real method call from a markup method call that creates new nodes.

We will also make some changes in the operator overloading area (particularly how the methods are named corresponding to the operator), and we may also provide a specific syntax for Groovy to support operator overloading, like operator +(a, b) {...}. The rest is more of implementation details than real changes, and there are some key language features which don't work yet perfectly -- for instance, the synchronized keyword is not supported yet.

We maintain an almost up-to-date To-do page on Confluence regarding the things we need to do before the final release: http://docs.codehaus.org/display/GroovyJSR/To+Do+1.0

As you can see, there's still a fair amount of work to do, the devil is in the details, but we're not that far from a final release.

Stelligent: When someone says "merci" how should one properly respond in true French?

Guillaume: Usually, we answer "de rien" (meaning "no need to thank me for that"). But it depends on the context. If you thank me for the interview or something like that, I'd tend to answer "C'était un plaisir" (it's been a pleasure) :-) Or even "De rien, c'était un plaisir".

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