Category Archives: Groovy

What makes a language Dynamic?

I read an article the other day on coding horror that discusses size is the enemy of software development. One of the opinions from the article was:

If you’re starting a new project, consider using a dynamic language like Ruby, JavaScript, or Python. You may find you can write less code that means more. A lot of incredibly smart people like Steve present a compelling case that the grass really is greener on the dynamic side. At the very least, you’ll learn how the other half lives, and maybe remove some blinders you didn’t even know you were wearing.

I agree 100% with this statement. Where the confusion often comes in is what makes a dynamic language “dynamic”. Is it because of dynamic typing? Is it strong vs weak typing? What about the presence of a MOP?

A lot of the buzz around dynamic languages has been created by the Ruby community, particularly around the Rails application. As described in the previous quote, dynamic languages provide features that allow you to write less code that means more. What about Ruby on Rails allows developers to write less code? There is more provided there than dynamic typing alone can provide.

So what is the definition of a dynamic language? Graeme Rocher had a great session at grails exchange on “Dynamic Groovy – Meta Magic” where he addresses this issue in the introduction. He defines a dynamic language as a language with a Meta Object Protocol (MOP for short). A MOP is (definition from Meta Magic):

A mechanism that makes the semantics of a program extensible.

This definition is a bit vague but in a nutshell it allows classes to be dynamically modified at runtime. Typically these languages also provide language level ways to intercept method invocation and property access.

There are many languages that support dynamic typing like Visual Basic, BeanShell, Ruby, JavaScript and Groovy but not all of these have a MOP. According to Graeme the main languages that support a MOP are Groovy, Ruby, Small Talk and LISP.

I do agree that a dynamically typed language like JavaScript allows the programmer to write “less code that means more”. The point that I’m trying to make is that a language that is dynamically typed AND has a Meta Object Protocol allows the programmer to write even less code than one that just has dynamic typing.

The meta object protocol is what allows applications like Rails and Grails to create and extend domain classes at runtime.

For this reason, I would recommend that if you are starting a new project, consider using a dynamic language like Ruby or Groovy. A dynamically typed language with a Meta Object Protocol allows you to write less code that means more than a language with no Meta Object Protocol.

Groovy for Java Unit Testing

I listened to a great podcast the other day on “Groovy Programming for Java Guys“. It was a really good look into the groovy language and how it relates to Java software development. I’ve sent this to management to try and help them understand better this whole “Groovy” thing.

My team has been integrating groovy code into our legacy Java project slowly over the last little while. Recently I have added it into our build scripts so Groovy can live alongside Java as a first class citizen. More importantly, now Groovy can be used in our unit tests. The groovyc ant task allows for joint compiling of Java and Groovy sources. This task is available with the new Groovy 1.5 release at

There are a lot of features that Groovy brings to unit testing Java code. A big one is using map coercion to create mock objects. Your Java code may use an interface or class that does some particular operation in production. You might not want to actually perform the operation in a unit test but verify that the operation was performed. Coercion allows us to create a mock object that acts as a particular class but has different functionality. For example, if you have a production class that sends an email:
class Mailer {
public void sendEmail() {
// Email sending code…

System.out.println(“email sent”);

You can simulate a Mailer by creating a map that maps method names to a closure. The as keyword coerces the map to act as the Mailer class.

def fakeMailClosure = {
println “fake email”
def testObject = [sendEmail: fakeMailClosure] as Mailer

Just a few lines of groovy can create dummy objects that can be used to do whatever you want in a test environment. The testObject can even be passed into Java code where it is treated as a real Mailer.

Grails is not Rails

I have been using Groovy for a little while now and am researching the possibility of using Grails for an upcoming project. At the time, I did not no much about Grails but I had dabbled with Rails a bit and got a feel for how it works.

The .NET community created a project called nant, the .NET port of ant. I’m also familiar with all of the various XUnit variants like JUnit for Java, NUnit for .NET, etc… I just figured Grails was a the Rails application for Ruby ported over to Groovy.

This was not the case at all. Both Rails and Grails are “coding by convention” web frameworks for the Ruby and Groovy languages respectively but they have very different design points. I was familiar with how ActiveRecord works in the Rails world and figured Grails would work the same. ActiveRecord takes a database schema and builds the Object model from the database. In Grails, Object Relational Mapping (GORM) instead using hibernate under the hood.

This article gives a really good summary of the differences in the design approach between Rails and Grails:

Ruby on Rails: RoR uses the bottom up approach where you define your model at the database schema level and RoR builds the model to match using naming conventions. You don’t even have to add the properties to your domain classes as RoR will add them based on the naming conventions of the db schema.

Grails: Grails uses the model-down approach where you define your model and it (or Hibernate technically) builds the schema for you. As I mentioned I don’t like this as a matter of taste since I don’t have as much control over the underlying model. To Grails’ credit, you can fine grain control the database schema by using Hibernate’s mapping, but what a pain.

Agile Dynamic Languages for Java

There has been a lot of buzz about Ruby in recent days, particularly around Ruby on Rails. I love these Ruby on Rails vs. X commercials that has created. Rails provides a much better framework for the “web backed by a database” problem than anything I have seen in the pure Java world. Java has become a very bloated language and even the so-called “lightweight” frameworks are large and clunky. Rails is a great alternative for most people.

But not for everyone. I work mostly with Java based server applications that do not fit the “web backed by a database” type of project. These applications could benefit from the Ruby language itself, but not much from Rails. I have looked into using JRuby as a way to leverage the strengths of the Ruby language on the Java platform.

JRuby is a Ruby interpreter written 100% in Java and therefore runs on the JVM. It allows you to have the benefits of Ruby but still be able to use existing Java code. My main issue with this implementation is that it does not inter operate well with Java. Code written for JRuby typically use the Ruby libraries which work distinctly different from their Java counterparts. This makes it difficult to create a hybrid application where both Ruby and Java is used.

This is about the time I found the Groovy project. Groovy is “an agile dynamic language for the Java Platform” ( It is a powerful dynamic language that has many of the sought after features of other languages like Ruby and Python. The key difference here is that Java is a first class citizen in Groovy. The Groovy libraries are built on top of Java, extending and modifying the core API. Groovy makes creating a hybrid Groovy/Java application possible and easy.

For those coming from a Java background, Groovy is very easy to learn. The syntax is very similar to Java with a twist. Semicolons are not required, getters and setters are not required for properties, code closures are available and metaprogramming is possible. If you are looking for Rails, there is Grails which is a web framework for Groovy.

So if you long to wet your feet in an agile dynamic language like Ruby but are stuck with supporting legacy Java applications, I would recommend giving Groovy a try.