Grails 0.1 Released

Yes, that time has come, the first 0.1 release of Grails is out and I'm really pleased all or our hard toil has resulted in such a quality release. Grails has come a long way, I'm currently developing my first live project with it and it is a joy to use. There is still much to do though and we have some exciting features planned.

Over the coming weeks I will be posting on this blog about some of the features of Grails that I believe make it unique and not just another Rails clone. So stay tuned, the Grails journey has only just begun. :-)

Grails at JavaOne 2006

Well the session listings were posted a few days ago on the JavaOne 2006 conference website and if you browse into the Web Tier track you can see the details of the Grails session (BOF-2521) I will be presenting. Here's a quick link if you're lazy.

By that point Grails will (hopefully) have been released and a bit more interest garnered, but in the meantime checkout what will be covered.

Another interesting note is that there are 5 sessions (yes 5! There may even be more as I did my best to go through all the sessions but may have missed one) covering or related to the Groovy language. Making it the most covered dynamic language at the conference which is great news.

Also, don't forget to take in Guillaume's session on 'Simplifying Enterprise Development with Scripting' (TS-1246) and to those who are going to be there (Bob, you coming? ;-), see you there!

Groovy & BeanShell: Dynamic vs Scripting Languages

In my previous post I talked about the fundamental difference between Groovy and BeanShell and in one of the comments I was asked to elaborate on why exactly Groovy is dynamic and BeanShell is not. So here it, BeanShell is a scripting language, it is to Java what VBScript is to VB, the syntax is near identical, you can copy and paste Java code into BeanShell and vica versa. This makes it highly useful for doing things like testing Java code in isolation, or trying out a Java API through an interactive BeanShell console.

It is 'dynamic' in the sense that it uses reflection to achieve a lot of these goals, but beyond the aformentioned use cases I would not choose BeanShell over Java to implement say a build system, or a my web actions, or do text processing, advanced regex, output templates, as a view technology, this list can go on...

The reality is that BeanShell does not provide any productivity gain so to choose to use it for a task over Java (rather than use it to script Java) has no real benefit and this is because it does not have any of the true features of a dynamic language like Ruby or Groovy. I'm a big fan of WebWork and I've been using Groovy to write XWork actions because the advantages are clear, I can save/reload changes, I can use closures to manipulate and sort my data model:

projects.findAll { it.status == 'open' }.sort { it.name }

I can use GStrings, a concept known as string interpolation in languages like Perl and Ruby, and multi-line string support to easily manipulate strings:

def user = User.get(1)

def message = '''
Dear ${user.name},

Thank you for registering with xxx site,

Your password is: ${user.password}.

See you soon!
The Site
'''


There are many more examples of the kind of expressiveness mentioned above that Groovy allows in its syntax, but more importantly than all these syntatic niceties and what makes Groovy truely 'dynamic' is how methods (as well as constructors, properties etc.) are dispatched. Groovy has the concept of a MetaClass and it contains the methods that a class 'really' has as well those added dynamically at runtime, allowing new behaviours to be attached to new and existing classes. This is a feature Grails uses extensively to add behaviours to controllers, domain classes, tag libraries etc. all while still retaining the ability to use inheritence.

The reality is that Groovy and BeanShell are not really competing with each other at all, and address different problems entirely: BeanShell the scripting language for Java and Groovy the dynamic, agile language for the JVM. That is why I hope that instead of seeing articles like those written recently, we'll see some from the same people entitled "Using BeanShell to Prototype Java Code" or "Using Groovy to Power your Build System" as writing "Groovy is rubbish, and BeanShell is great" or vica versa is really not helping any newcomer who is interested in this space make an informed decision on which is the appropriate language for their use case.

Groovy: The Ed Burnette Effect

So as typically is the case when a few positive posts arise about Groovy, an alternative view point has cropped up entitled "BeanShell: groovier than Groovy" by Ed Burnette. The article quotes only the last paragraph of my previous post about how Groovy is approaching its "second" version 1.0, conveniently brushing over and failing to comment on any of the benefits highlighted.

Unfortunately, this is where many Java developers, with all due respect to Mr Burnette, fail to understand what a "dynamic" language is and its a shame this misunderstanding is being spread. I like BeanShell I appreciate what they are trying to do and in certain circumstances would recommend it over Groovy. It is great for embedding in Java applications if you want to script say an application server or or server component, but the fundamental difference is that BeanShell is a scripting language for the Java language, whilst Groovy is a "dynamic" language for the JVM (note the difference between Java the language and the JVM).

BeanShell is essentially Java without the need to specify types, which is great in certain circumstances, but doesn't really have much productivity gain and is not in my opinion the answer to the JVMs dynamic needs. I have written a lot of code in both BeanShell and Groovy and with Groovy my lines of code (LOC) count is about 60-70% less then the equivalent Java code, with BeanShell this is about 10%, as its essentially just Java without the need for type safety.

This is also why BeanShell has managed to achieve relative stability and a small size (as highlighted in Ed's article) when compared to Groovy as its goals are relatively simple. Groovy adds new language constructs, closures, the GDK methods, builders, meta-programming etc. This is not something you can achieve without spending a longer period of time defining the language and the API. Yes, following the standardisation process there was a re-think of many of the aspects, but this is the usual process with the JSR and any standard spec. Fortunately the syntax, through this process, has been nailed down and the Groovy development team are merely focusing on improving the core of Groovy.

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.