Thursday, March 02, 2006

Groovy: The Sleeping Giant, an Elaboration

Richard Monson-Haefel recently wrote an interesting blog post about
Groovy, titled "Groovy: the sleeping giant". The post talks about the dynamic future, which is certainly coming with the increase in popularity of agile methodologies and Ajax in particular spurring it on, and talks about how Groovy could be the solution the Java platform needs. The interesting thing for me though, is although I agree with many of the points I do disagree with some.

Firstly, I believe in a blend, its not going to be dynamic everything. The fact remains there are still huge benefits to compiled languages such as Java especially in large systems where the benefit of refactoring and powerful IDEs becomes clear. But, it is there where Groovy's true strength lies in its ability to cleanly interface with Java. In addition there are other, largely undocumented, reasons why Groovy has huge amounts of potential:
  • Meta-programming - Groovy has the ability to inject methods, constructors, properties, fields, etc. into ANY java class at runtime. Most of what AOP is used for nowadays can be achieved with Groovy's Meta-programming capability. No byte-code manipulation a la AspectJ, this is awesomely powerful and in combination with Groovy's support for closures and builders it makes it possibly to create mini-DSLs
  • Power Features - Although there has been a lot of argument about the optional parenthesis, and the optional semi-colons etc. There are very good reasons for these things being optional: For combining closures and method calls to allow builder syntax. Builders and closures are very powerful, especially when you consider you can pass the same closure to a multiple different builders. Why you say? Well one may output a tree structure as XML another might render a GUI from it, I'll leave the rest to your imagination.
  • True Object Orientation - Everything is an object in Groovy, you may think this is strange given Java has primitive types, but all the auto boxing and unboxing happens at runtime, no Java 5.0 required. This means you can have methods on numbers, overload operators by adding a specifically named method call, use advanced switch statements that don't just work with char and int.
  • Grails - Ok I'm biased on this one, but I believe Grails has huge potential to succeed in areas where Rails has unfortunately been unable to penetrate. On those thousands of companies that have invested huge amounts of money in Java and are not about to dump that $35k per CPU application server. For those who have legacy database systems that need to be mapped onto, existing Java services that need to be interfaced with seamlessly and team of developers all skilled in, you guessed it, Java.
So there you have it, Groovy has had its problems, and the FUD that has been spread hasn't helped. But, Groovy is still young, 10 years younger than Ruby in fact, and a fantastic amount has been achieved for it to be where it is today. I look forward to the upcoming release of Groovy 1.0.

5 comments:

Anonymous said...

I'm sorry, but I can't handle @Property in Groovy. That should be the default. It may seem small, but I think it's just killer (in the suicide way, not in the beating the competition way).

Graeme Rocher said...

This is to align it with similar code generation mechanisms in other languages. The syntax essentially generates a getter,setter and private field.

To me it helps clarify what I'm doing as I'm not just adding a field I'm adding a javabean property, if you don't like it write normal javabean getters and setters or just use public fields

Anonymous said...

I thought that the syntax issues with Groovy had still to be sorted out - is this the case?

Graeme Rocher said...

The syntax issues have been resolved, the Groovy team are focusing on improving the core now. See my latest post.

Anonymous said...

Good Job! :)