Greetings from the Groovy/Grails Experience
Thursday, February 21, 2008 at 11:00PM
Ken Rimple in Events, Groovy/Grails, Technologies, conferences, grails, groovy

I'm sitting here in my hotel room thinking about just how far we have come in terms of productivity as developers over the last decade. In 1998, I was working on a very new Java platform, doing command-line work and primitive (if any) web servlets. It took forever and a day to write those applications, and since Java was so new, nobody knew how to tune them.

Spin forward 10 years, and here we are, experiencing the dawning of the dynamic language era. Most programming languages are statically typed, meaning that variables and methods must obey strict data type conventions. Also, traditional language semantics are locked down, so that if you don't like how a given language or framework functions, you have to figure out an elaborate set of workarounds to correct it.

Developers are becoming aware of dynamic languages like Ruby and its' web framework, Rails. They are investigating domain specific languages as well. These languages create a syntax to allow business and development teams to work closely together and express what they want to do in the form of almost english syntax.

Trouble in Paradise...

But the number of languages available to programmers is mind-numbing. We can't use Java, that's behind us. How about Ruby? JPython? JavaScript? ActionScript? Scala? Haskell? Obviously I'm just listing names here, but you get the picture. Although each language has its' strengths and uses, there happen to be a dizzying array of them to choose from.

Ok, let's stick with Java. If we do, we now have another set of choices to make:

Whew, I'm exhausted just thinking about it.

What if there was a better way?

What if you could keep those Java developers working in a language that was familar to them? With the same runtime. With a rich set of additional, dynamic and robust features that, once mastered, make that language much more powerful? What if we could harness tools like Hibernate and Spring without creating complex configuration files? What if we wanted to use an already popular charting library, or integration framework? What if we could just be productive and agile but not throw away all of the good tools and libraries we've put to use over the years?

Groovy is just such a language. It supports dynamic language semantics, including the ability to modify a class to weave in a definition:

// Use Expando Metaclass to
// add a method dynamically
String.metaClass.getLength = {
-> delegate.size()

// now, use this method
// in any String
print "Hello there".length
> 11

Didn't you just hate the fact that Java didn't have a getLength method on java.lang.String? That two-line setup fixed it. But I digress...

Groovy lets you get rid of getters and setters, constructors, equals and hashcode methods. Any variables you define are automatically given dynamically created setters and getters, when called from within Java. Oh, did I mention you can call Java from Groovy, and Groovy from Java? In fact, renaming a class as a .groovy file, and removing all of the constructors, getters and setters can actually increase your code coverage!

This means that Groovy allows you to become ultra-productive, but from within a language and runtime you've already worked with for years.

Grails -- A rapid application development platform with tools you know...

Remember that list of things to consider in building a Java web application framework? Well, Grails is a Groovy and Java-based application delivery platform that makes some choices up front based on industry adopted tools. When you create a grails app (I will pause while you jump ship and google "creating a grails application") you are generating an application that is based on some strongly adopted building blocks:

Grails supports scaffolding (the ability to dynamically generate the web site views while focusing on getting the database mapping elements called Domain Objects right). Grails also supports easy unit testing with a GroovyTestCase class. The Groovy Server Pages are easy to pick up, and a tag library build process is as easy as grails create-tag-library and editing your tag in the resultant file.

In my next post, we'll talk more about Grails, and discuss the G2One Groovy Grails show itself. I'll provide some links to tutorials and samples, and discuss some specific news coming out of the conference itself.

Article originally appeared on Random Thoughts (
See website for complete article licensing information.