Groovy 1.7

Today Groovy 1.7 was released.

The main features are:

• Anonymous Inner Classes and Nested Classes (Java Style)
  
• Support for annotations on imports, packages and variables declarations
  
• Grape enhancements (now it's possible to add a @Grab annotation on inports or variable declarations and download the requested dependencies from a repository)
• Power asserts that provide a descriptive message of what was wrong, like in the Spock Framework (real cool !)
• AST viewer and AST Builder
• Customizable Groovy Truth through the implementation af the asBoolean() method
• Improved Groovy Console
• SQL batch updates and transactions

A more detailed description of the new features can be found in the Groovy site.

Is Groovy such terribly slow ?

A thing you hear often is that Groovy is not a good language because of its performances. Actually Groovy IS slow. Depending on the type of task, it can be from 10 - 15 times to 90 times slower than the equivalent Java version. And is usually much slower than Scala too. (By the way, Scala seems to be the hot language of the moment, what Groovy used to be 1 year ago...).
And the reason why Groovy is so slow is quite clear. To add all the metaprogramming magic, Groovy has to dispatch every method (even the ones that don't use metaprogramming) dynamically.
So, the best thing we can do is to stop using Groovy, go back to POF (Plain Old but Fast for those who love acronyms) Java and maybe start learning Scala...
Well...no.
There are a lot of reasons to keep using Groovy.
Performances are constantly improving at every new version. There is even an attempt to create a partially statically compiled version of Groovy (see the Groovy++ project). They are tryng to offer a better support to concurrency throught the introduction of the "Actors Pattern", present in languages like Scala and Erlang (see the GPars project). Maybe I will write a post on these two projects someday. So, there are a lot of efforts on this topic. And then there is a very important reason...the killer application of Groovy.
Grails.
Of course Grails is based on Groovy, and extensively uses Groovy metaprogramming capabilities: so Grails performances are not so exciting. But it will take benefit from the improving performances of Groovy. And they are also working on big improvements on the performance side. As announced in the recent Groovy and Grails Exchange, (by the way, great event!) they are working on the precompilation of the GSP, maybe one of the biggest bottleneck in Grails. The number of request per second that Grails will handle in version 1.2 will double compared with older versions. And then, is the language speed so important when your application works with databases ? And with the network ? The weakest parts are others, not the language itself. With the current version (1.1), without GSP optimization , Grails performances are already comparable with the ones of other popular web frameworks (Tapestry, Wicket, Seam). But Grails is far mor productive than most of other frameworks.

So, is Groovy a slow language ? Yes, it is. If I want to develop an performance critical application with tons of business logic and number crunching, Groovy is not my first choice. But you shall not use the same tool for every job. (and yes, the language is a tool, even if a very important one, to build applications). For other kind of applications, the boost of productivity will overcome the performance issues. Do you remember what C++ developers were saying when Java came up ?

Modify XML with groovy

One quite common thing to do when working with XML is to manipulate nodes: remove or rename attributes, changing values, remove or append nodes, and so on.
With Groovy's XmlParser this is quite easy, as explained in the official documentation.
Here are some more complex examples.
Suppose you want to set an attribute value, or to add the attribute if it doesn't exist. You can use this code:

if (!node.attribute('myAtt') {
    node.attributes().put('myAtt', 'myValue')
} else {
    node.attributes()[myAtt] = 'myValue'
}

If you want to rename an attribute:

def origAttrs = node.attributes()
if (origAttrs.containsKey(oldAtt)) {
    origAttrs[myAtt] = origAttrs[oldAtt]
    origAttrs.remove(oldAtt)
}

Suppose you want to replace a child node with another one (in the same position). Since the children() method returns a list of nodes, you can do like this:

def newChild = new Node(node, 'newChild', ['att1': 'val1'], 'New Text')
def indexOfChild = node.children().findIndexOf {it.name() == 'oldChildName'}
if (indexOfChild != -1) {
    node.children()[indexOfChild] = newChild
    newChild.parent = node
}

In this case we replace the child if there is only one node with that name, otherwise we replace the first one. Of course it's quite easy to replace all the children with a given name.

You can add these methods to a category or to the metaclass of the Node object to have them ready whenever needed.

Jug - Groovy Testing Techniques

Last week I made a second presentation about Groovy to the JUG Milano. It was not a continuation of the Grails tutorial I started last time ( which will be continued with a more 'hands on approach'), but was an introduction of the techniques that Groovy provides for testing Groovy and Java code. You can find the slide on Slideshare

Groovy Testing

View more presentations from Davide Rossi.

Grails & Spring together...

The news is fresh, and unexpected, but big, very big for the Groovy / Grails world. G2One, the company behind Groovy and Grails technologies, was acquired by SpringSource, the company of the popular Spring framework (read the news). What does this mean for the future of Groovy and Grails ? From the technical side, Grails is build on top of Spring, so the integration between the two technologies can be more tighter in the future. Also, SpringSource can dive into the world of dynamic languages backed by a mature and fast growing technology. But the most important thing is not technical but commercial. Backed by SpringSource, Grails will enter in the arena of enterprise applications from the front door. The technology is very good for big projects, as the social network LinkedIn and UK TV broadcasting giant BskyB sites demonstrate, but is still facing a lot of resistance in big and meaningful projects, maybe because it's considered too new or not reliable...This is likely to change in the future as a result of this acquisition. Tell your boss, and to the big boys in your company...Grails is going to become mainstream...