Jazoon ’09: The King (aka König) speaks!
Session title: Groovy – seven usage patterns
Dierk begins firstly by emphasising that Usage Patterns are not to be confused with (GOF) Design Patterns, secondly by stating that the intent of Groovy is not to replace Java but to make the life of the Java developer easier.
Up front: I won’t attempt to describe all Dierk’s patterns here in detail, but will limit myself by noting the quintessence …
Pattern #1 “Super glue”: Hook large components i.e. middleware, frameworks, widgets etc… together.
Dierk now engages in an act which I swore I’d never attempt myself live and on stage: Live coding! And boy Dierk can type fast!!!
Ah ha… naughty but amusing… The typing is being done by an app.
Regardless: With just a few lines an RSS feed is shown in a Swing GUI including a table, a scroll bar. Very nice.
Pattern #2 “Liquid Heart”: Externalise business models because they need to constantly reflect our changing understanding of the business problem. The “liquid” here is, for example, a rule that needs to be dynamically changed. In this case Dierk invokes Groovy from Java. The Groovy functionality can be exchanged at any time… even runtime.
Pattern #3 “Keyhole Surgery”: Minimal invasive surgery “in vivo”
Dierk shows how Java objects can be seamlessly addressed (in-line) in Groovy statements and expressions. This means that with very little code we can wrap existing code and add some additional functionality. Dierk mentions how this was recently used to great effect as part of a SAP mandate, saving days of work as a result.
Pattern #4 “Smart Configuration”: Enhance configuration with logic
This is a common pattern in Groovy. Whereas Java apps tend to use XML for configuration, Groovy makes extensive use of itself as the configuration mechanism. Dierk shows an example taken from Navis. Instead of having one config file per client, Navis now has a single config file (in Groovy) which handles all the desired configurations.
Pattern #5 “Unlimited Openness”: Every line of code may be changed
Dierk cites PlanetRIA (planetria.org) as an example of where vey little code change was required to create a new app based on an existing one – which in this case was groovyblogs.org.
Pattern #6 “House Elf”: Delegate the housework
Example: Use the Groovy ant task to introduce novel functionality to ant at the time the ant script is running!
Pattern #7 “Prototype”: Feasibility study on the target platform
Groovy is ideal for rapid prototyping. Dierk explains how Canoo uses functional prototypes as a partial replacement for a complex, static description of the application’s intent, such as is found in most tenders made to clients.
A cool example involving prime numbers follows. Groovy’s category feature is used to introduce a count of the number of times the modular operator is invoked, which subsequently leads to a vastly improved algorithm.
In closing Dierk mentions a couple more patterns which are in the pipeline: Lipstick, Ghost Writer. For more information on Groovy usage patterns: Wait for Groovy in Action 2nd ed.; out later this year.
Just two question from the audience: What’s the best IDE for Groovy development. Answer: At the present time IntelliJ, but improvements are on the way for Eclipse. Next: How reliable and easy-to-use are AST transformations? Answer: A junior developer recently succeeded in developing an AST-based solution in just a few days, as part of the PillarOne project.
Read a french Blog about Dierk’s talk!
