- You tend to get kicked out of a room before the next session anyway to ensure that registered individuals get equal opportunity to ‘the good seats’ (and probably to make sure someone not registered for the session doesn’t displace someone who is registered for the most popular sessions)
- This is the longer-than-normal one-hour break (no such break tomorrow on the final day of JavaOne 2012)
- The outside temperature is significantly lower than yesterday and it’s refreshing to stand in a shaded area outside while a cool breeze blows between the buildings
Laforge introduced himself and the way he says his own name with intentional French accent is far cooler than how I pronounce his name. He is the Groovy Project Manager at VMWare, the initiator of the Grails framework, creator of Gaelyk, and a co-author of Groovy in Action. Laforge is another speak who likes to take questions as they come.
Laforge listed some features introduced with Groovy 1.8 command chains, gpars (concurrency/parallelism), closures improvements, built-in JSON support, and new AST Transformations.
Laforge showed a command chain that looked like English words but is really an alternative combination of methods and parameters (every other word is a method name with the words in between being the parameters to the preceding method name). With some exceptions, command chains allow code to be written without parentheses and some other types of punctuation. He showed several examples of this, including use of commas for multiple arguments. He also explained that no-argument methods do require parentheses.
GPars is ‘bundled in the Groovy distribution’ with Groovy 1.8 and ‘covers a wide range of parallel and concurrent paradigms.’ He emphasized that this can be used ‘from plain Java as well!’ GPars is friendlier for Groovy developers.
Closure annotation parameters is the ability to use closures within annotations. This is achieved by encoding the closure in the form of a class.
Because ‘closures are used a lot in the context of functional programming’ and because Groovy has a ‘functional flavor especially with the use of closures,’ Groovy closures in Groovy 1.8 support closure memoization. This feature potentially brings performance improvements due to caching of results for same parameters to the same closure. More granularity in terms of the number of times to use cache for closure results is available via methods like memoizeAtLeast, memoizeAtMost, and memoizeBetween.
Laforge explained that Groovy introduced from the beginning powerful XML marashaling and unmarshaling capabilities ‘back when XML was popular.’ He said it was thus quite natural to add built-in JSON support similar to that XML support. He then showed code samples (embedded within the slides like I prefer) indicating how to use JsonSlurper to consume JSON content and how to use JsonBuilder to generate JSON content.
Groovy 1.8 introduced some new Groovy ASTs as discussed in the earlier JavaOne presentation A Walk Through of Groovy’s AST Transformations. He had some nice slides that combined simple text bullets of select AST Transformations with a simple code snippet using that AST Transformation. The new Groovy 1.8 AST Transformations that he covered included @Log, code execution controlling (@ThreadInterrupt for example), @ToString, @EqualsAndHashCode (similar transforms to Project Lombock), @TupleConstructor, @InheritConstructors (replicate all parent class’s constructors such as when writing a class that overrides Exception).
At exactly the half-way point in his presentaion, LaForge transitioned to coverage of Groovy 2.0. He stated that it was released in June 2012 and some ‘other dot releases’ have been released since then with ‘bug fixes and so on.’ The key themes of Groovy 2.0 include modularity, JDK 7 alignment,
Groovy’s single ‘all’ JAR ‘weighs in at 6 MB,’ but ‘nobody needs everything.’ The new core JAR in Groovy 2.0 is half that sizs (3 MB) and there are module-specific JARs. The ‘big Groovy old JAR’ is still available if you’d like to use it.
The effort to make Groovy modular led to the ‘extension modules‘ concept. This allows a developer to ‘contribute instance extension methods.’ This feature works with static type checking and is IDE friendly, two advantages that some of the other Groovy approaches for adding dynamic methods do not equally enjoy. These are structured similarly to Groovy Categories and require a descriptor in META-INF/services/org.codehaus.groovy.runtime.ExtensionModule.
Because ‘Groovy supports 99% Java syntax,’ Groovy supports JDK 7 enhancements such as underscores in numeric literals, multicatch exception handling, and better runtime performance due to use of invokedynamic.
One of the biggest new features in Groovy 2.0 is static type checking, which Laforge’s first bullet put this way, ‘Goal: make Groovy compiler grumpy!’ Laforge went on to show Groovy code samples with things in the code that will lead to compile-type breakage. He showed off the @TypeChecked annotation. There are aspects of Groovy that cannot be type checked by a compiler. An example of this is the builders prevalent in Groovy. This is what makes using @TypeChecked useful: use it where type checking makes sense and not where it doesn’t make sense.
Laforge went on to show how Groovy allows avoidance of explicit casting after an instanceof check as a specific example of Groovy’s type inference. Another Laforge example demonstrated how Groovy’s static type checking catches changing of data type in the same code.
Laforge listed several ‘gotchas’ with static type checking. For example, static type checker cannot allow use of dynamic metaClass. Another gotcha example is that the implicit ‘it’ variable in a closure body cannot be assured to be a certain type. There is a Groovy Enhancement Proposal to make it so that this situation can be type checked. It seems that anytime Groovy cannot guarantee the type during static type checking, that situation is not allowed. This does seem to be the safest approach.
Advantages of static Groovy code include type safety, faster code, and immunity from monkey patching. The price for this is loss of dynamic features and dynamic dispatch. One audience member asked why one wouldn’t always use static compilation and the answer is that many of us like being able to use the builders and other Groovy dynamic features. You can use the @CompileStatically annotation for portions to be compiled statically.
Groovy 1.8 primitive optimizations have dramatically improved performance and Groovy 2.0 static compilation closes gap with Java in Fibbonacci, Pi Quadrature, Binary Trees micro benchmarks. (Laforge did issue the usual caveats about performance benchmarks.)
Groovy 2.0 introduces modularity, Project Coin, invokedynamic, static type checking, and static compilation.
One interesting side note that Laforge mentioned is that ‘it is possible that Groovy 3 will require JDK 7’ (to use invokedynamic). Laforge’s slides are already posted online.
Reference: JavaOne 2012: What’s New in Groovy 2.0 from our JCG partner Dustin Marx at the Inspired by Actual Events blog.
