RE: Groovy and Grails: Three Worries

I had the pleasure of meeting and having dinner (at a wondefully steriotypical American diner) with Stuart Halloway along with other NFJS guys like Ted Neward and Brian Goetz at JavaOne. Since then Stuart took the time to write a nice entry with a few pleasantries that he discovered about Groovy & Grails (Thanks Stuart!).

In a follow-up post entitled Groovy & Grails: Three Worries he raises a few concerns which I commented on, but would like to take the time to address here too.

1. Lack of Open Classes in Groovy

His first concern centers around the fact that Ruby has an open class system whilst Groovy does not. The reasons for this are simply Groovy compiles into byte code directly and there is a one-to-one mapping between a Groovy class and a class file. This is unlike JRuby where you need to to use proxying trickys in order to do things like call Ruby from Java.

So essentially Groovy can't modify classes directly because as far as the JVM is concerned once a class is loaded it cannot be changed. Of course this is completely sensible as the Java platform has the concept of threading. Changing class definitions at runtime in a multi-threaded environment would be rather problematic from the JVMs perspective. Since Ruby has no concept of threading at this time of writing the language and runtime has no such concerns.

So given these constraints in Groovy we have a different way of doing things. Stuart presented the following example:

class Person { 
  def firstName; 
}
p = new Person();
class Person {
  def lastName;
}
p.lastName = 'Halloway'

In Groovy (with the upcoming 1.1 release) this would be implemented as:

class Person { 
  def firstName; 
}
p = new Person();
p.metaClass.lastName = 'Halloway'

p.lastName = "Rocher"

This uses Groovy's ExpandoMetaClass mechanism. Since in Groovy we can't change classes, we instead have a MetaClass for each java.lang.Class. The MetaClass defines the behaviour of the actual class. You change the MetaClass you change the class. So Groovy might not have "open" classes, but it has an equivalent mechanism for achieving the same thing.

2. OMG! Grails is not written in 100% Groovy!

Yes that is right Grails is around 80% Java and 20% Groovy. The reasons for this are several. Firstly, Java still makes a great language for writing low-level plumbing code. For dealing with all the complexities that the users of the higher level interface (Grails users) don't have to deal with. Secondly, since Grails is written in Java we get the performance benefits of this. Grails is between 50 and 300% faster than Rails depending on the test. Rails might be implemented in 100% Ruby, but it has very well documented performance troubles because of this.

Do we eat our own dog food? Hell yeah, we have a plug-in system where plugins are all written in Groovy. All of our custom tag libraries are written in Groovy. Groovy Server Pages (GSP), our view technologies, is all Groovy. So we eat plenty of it trust me. Finally, the Groovy community has never been the one to cry out and tell everyone to ditch Java. No, our philosophy is to choose the right tool for the job, and Java is still a great tool in my toolbox just as Groovy is another. The fact that they work so seamlessly together is what makes the pairing so special.

3. The old static typing debate

So is static typing useful anyway? Well yes, it has been useful for a number of things for us such as enabling us to implement more intelligent scaffolding based on the types (java.util.Date, java.lang.String) etc. Also we could implement things like command objects which using static type information.

In addition at the moment the tool support just is not there yet to use either Ruby or Groovy for large complicated applications. Static typing analysis and the features that it brings to modern IDEs like refactoring and code navigation are just in a different league in Java. I hope this will change in time and since Groovy supports both static and dynamic typing I believe the tools vendors will have an easier time creating quality tools for it.

This is also where Grails fits quite nicely into the picture as it allows you to mix Groovy for the simple to medium complex stuff and Java to do the heavy lifting. IMO Groovy gets the balance here just right.