The second JavaOne 2010 session that I attended was in Parc 55. Fellow SpringSource employee Jeff Brown presented in place of Guillaume Laforge, who was not feeling well. Brown stated that he works on Grails and thus works quite a bit with Groovy. The session was in a smaller room, but it was pretty close to full capacity and the majority of attendees raised their hands when Brown asked who was already using Groovy for development.
Brown began Laforge's presentation by introducing features that were new with Groovy 1.6. These include multiple assignment, return being optional in more cases (this has never been particularly useful to me, especially because its not always optional), compile-time changeable code via AST (Abstract Syntax Tree) Transformations (performance benefits because at compile time rather than runtime), Grape, metaprogramming additions (ExpandoMetaClass DSL and runtime mixins).
Brown introduced the section of his presentation on Groovy 1.7 by stating that Groovy 1.7.5 was released just a few days ago. Groovy now supports anonymous inner classes with same syntax as used in Java. This can be an issue for Groovy code written with constructors that accept a closure because that mechanism is now used for the Groovy anonymous inner class support. The anonymous inner class support was added to allow for greater copy-and-paste capabilities from Java to Groovy, but Brown does not recommend that approach (copying and pasting from Java into Groovy) in general. You can also coerce a closure into an instance of a specified interface. Groovy's support for nested classes now looks like Java's syntax for nested classes.
Unlike Java, Groovy allows a developer to annotate an import statement or a package statement. This can be useful for indicating dependencies and where to acquire dependencies. The @Grab annotation allows specification of dependency details (especially useful with Grape).
Groovy's "power asserts" provide more information when an assert statement fails. The AST Viewer is another useful tool in the Groovy development cycle that was introduced recently.
Brown also cited Groovy's significant JDBC enhancements that include explicit support for batch SQL. He also demonstrated how a developer can now override "Groovy truth" for his or her object simply by implementing the asBoolean() method on that class.
Brown stated that most of the Groovy 1.8 features he is starting to talk about are already on the 1.8 development branch. He covered features coming in Groovy 1.8 such as closure composition, improved DSL support (fewer parentheses and commas), etc.
Brown reiterated how easy it is for Java developers to learn and start using Groovy. This has been my own experience and my experience observing fellow Java developers first exposed to Groovy and watching how quickly they pick up Groovy. Brown also stated in his summary that Groovy is more than a language; "it's a very rich and active ecosystem" (Grails [web], Griffon [desktop/Swing], Gradle [build system], GPars [concurrency], Spock [testing], Gaelyk [Google App Engine]).
One of the questions asked during the question and answer period was regarding Groovy performance. Brown explained that Groovy has to do significantly more than Java does for method dispatch to support all the dynamic features in Groovy that are so popular. However, he also stated that he and others at SpringSource had worked with customers developing significant applications based on Groovy and Grails and had not seen any significant performance problems in those applications.
I think Jeff Brown did a good job of covering for Laforge and wasn't disappointed that I attended this session.