Grails at JAOO 07

Just finished my talk on Grails at JAOO. It went very well, the room was packed out with people having to stand at the back. Grails was extremely well received and the audience enthusiastic.

The conference seems interesting, there aren't many low level technical talks. Most talks seem to be design or patterns or enterprise architecture talks. There are also many .NET talks, so its quite a diverse conference. An interesting concept.

JAOO uses a system of rating talks with red, yellow and green papers depending if the talk was rubbish, average or good. I managed 15 yellows, 98 greens and no reds. Not bad :-)

The new meta-programming APIs in Groovy 1.1 beta 3

As announced by Guillaume, Groovy 1.1 beta 3 is out and the final release is just round the corner. There is lots of good stuff in there, but I want to talk here primarily about the new meta-programming API improvements that have been introduced in this release.

Groovy has always had the underlying Meta Object Protocol (MOP) that allowed the same behaviour as languages such as Ruby and Small Talk, however the API onto these has, up until now, not been as elegant as it could have been. With Groovy 1.1 beta 3 there is a lot more at your finger tips including...

Runtime evaluation with respondsTo & hasProperty
It is now a lot easier to inspect the runtime thanks to the addition of hasProperty and respondsTo for meta classes so you can do:

class Foo {
    String name = "Wilma"
    def sayHello() { println "hello $name" }
    def sayHello(String message) { println "hello $message" }
}
def f = new Foo()

if(f.metaClass.respondsTo(f,'sayHello') {
    f.sayHello()
}

Since Groovy supports method overloading and typed arguments to support good Java interoperability you can also specify a type:

if(f.metaClass.respondsTo(f,'sayHello', String) {
    f.sayHello("Fred")
}

Groovy also differentiates method and property access so you can do this:

if(f.metaClass.hasProperty(f,'name') {
     println f.name
}

See the docs here for more info on hasProperty and respondsTo

Missing method/property interception with methodMissing & propertyMissing

As of beta 3, Groovy now supports the concept of "method missing". It has always been possible to intercept method dispatch using invokeMethod. However, this has the overhead of intercepting every method call instead of just the "missing" ones. As of Groovy 1.1 beta 3, Groovy now supports "method missing" and "property missing", which are only called when method dispatch fails (ie just before a MissingMethodException would be thrown anyway.)

A trivial example can be seen below, we use this feature in Grails to implement dynamic finders such as findByTitleAndAuthor("Groovy in Action", "Dierk Koenig"):

Foo.metaClass.methodMissing = { String name, args ->
    Foo.metaClass."$name" = { Object[] varArgs -> 
        "$name : ${varArgs.inspect()}" 
    }
    delegate."$name"(args)
}

def f = new Foo()
f.sayHello('Fred')
assert f.notARealMethod("boo") 
            == 'notARealMethod : [["boo"]]'
assert f.notARealMethod("boo", "hoo") 
            == 'notARealMethod : [["boo", "hoo"]]'

Notice how in the example above we can dynamically register a new method on the fly and then call that method. This also has the implicationthat the next dispatch to the same method is faster. See the docs here for more info and there are a whole load of docs on doing dynamic Groovy and meta-programming to be found here.

Gavin King saying nice stuff about Groovy/Grails

Gavin King has been featured in a podcast where he has some nice things to say about Grails. Transcript here. Thanks Gavin! For what its worth Seam makes JSF palatable ;-)

In related news Gavin also has a blog post about the downside of ActiveRecord storing model info in the DB. The funny thing is this is nothing new, we realised that having your model in the DB was a crap idea from day one when we created Grails. That is why GORM has not such deficiencies.

David HH Living in Cloud Cookoo-land

This latest little outburst from David HH of Rails fame is hilarious. Even Charles Nutter must be on the floor laughing. David honestly believes that JRuby is a bridge for people to move to the C Ruby runtime because its a superior environment without the "junk"? I had to do a double take when I read that.

So let's see, enterprises are going to give up on a platform that provides monitoring, profiling, JIT, a deployment architecture that isn't a joke, threading, a compiled byte-code format, clustering, distributed caching, transactions that don't suck, maturity and performance all to build Rails apps?

Ignore the enterprise, it is ok. Grails is settling in quite nicely in the enterprise, and everything else will flow from there ;-)