#52WeeksOfCode Week 33 – Groovy

Week: 33

Language: Groovy

IDE(s): Eclipse with Groovy plugins/Groovy Shell


History (official):

(From the Groovy Home Page)


  • is an agile and dynamic language for the Java Virtual Machine
  • builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
  • makes modern programming features available to Java developers with almost-zero learning curve
  • provides the ability to statically type check and statically compile your code for robustness and performance
  • supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
  • makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
  • increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
  • simplifies testing by supporting unit testing and mocking out-of-the-box
  • seamlessly integrates with all existing Java classes and libraries
  • compiles straight to Java bytecode so you can use it anywhere you can use Java

History (real):

Since this is the third or fourth language I’ve encountered that produces code for the Java Virtual Machine (JVM), I decided to search for “java is dead”:

Searching for "java is dead"

Searching for “java is dead”

Apparently the Java Death Watch has been around since 1996. This raises the bigger question “When is a programming language actually dead?”.

According to the Linguistics Society of America, a human language is considered dead when there are no more native speakers.

Computer languages are trickier. Is a programming language dead if no computers are left to run it or is it when there are no programmers who still use it? If we decide to adapt the definition of ‘dead’ from human language (no more native speakers), we need to ask “What is the computer equivalent of a ‘native speaker’?” This puts us back to square one so that’s no help. We should probably just see how good of a case we can make for either choice.

  • Computers as ‘Native Speakers’ – Computers actually ‘speak’ machine language, 1’s and 0’s. This is very hardware and operating system specific, like different dialects of English (same characters different syntaxes). Every programming language command has to eventually end up translated (directly or indirectly) into machine language. For modern coding languages, the underlying hardware doesn’t make that much of a difference. This argument is a non-starter.
  • Programmers as ‘Native Speakers’ – This makes more sense to me. The code is still around and still runs but nobody is writing new programs with the language, then the  language is dead. Or, to use the phrase of art, in ‘maintenance mode’. (see COBOL)

Groovy is another scripting language that produces code that can run on the Java Virtual Machine (JVM). Others include JRuby, Scala, Vala, Fantom and Jython. In effect, they are all dialects of Java, since you can mix Java code with any or all of them and they run just fine.

So is Java dead? Let’s just say that the rumors have been highly exaggerated.


Groovy is cross-platform and there are a number of ways to install it.

  • Download the binary package and unzip it wherever you want
  • Install the Groovy plugin in either Eclipse or NetBeans
  • If you’re on a UNIX-based machine (like Mac OS X or Linux), you can install the GVM (Groovy enVironment Manager).

I already had Eclipse after installing the Scala IDE (i.e. Eclipse with the Scala plugin) so I went with the  Groovy plugins for Eclipse. It was pretty straightforward.

Once I plugged in the location of the Groovy software, I got a nice selection of add-ons. I just selected what I needed:

Minimum Groovy plugin install

Minimum Groovy plugin install

A quick download, install and restart of Eclipse and I was off to the races. When I came back, there were additional choices in my New menu:

Starting a new Groovy Project

Starting a new Groovy Project

I selected Groovy Project, took the defaults and (like the Scala project) opened up with no source code, just project scaffolding. I had to add a Groovy class to the project to get some source I could work with.

There are three ways to run your Groovy code:

  • Run as Java Application – This compiles Groovy into Java bytecode and runs it on the JVM
  • Run as Groovy Script – Don’t compile, just run the script with the Groovy interpreter.
  • Run as Groovy Console – This is the most interesting option to me. When you choose this, your code opens up into a separate window:
Running in the Groovy Console

Running in the Groovy Console

This gives you an interactive console where you can do some quick experimentation with your code. This is a good choice for rapid development, letting you test out chunks of code before rolling them back into your main project.

Since I’m also comfortable with the command line, I installed the GVM for good measure. It’s pretty easy and gives me access to a command-line Groovy interpreter. Like the Groovy Console, this lets me test out chunks of code for rapid development. Once it’s installed you just call it with the command groovysh:

Starting up Groovy Shell

Starting up Groovy Shell

A sample Hello World in groovysh:

Running Hello World in Groovy Shell

Running Hello World in Groovy Shell

This is not the preferred option for Groovy newbies. I would recommend that you stick with Eclipse or Netbeans.

One of the things that interested me about Groovy was the claim that you can drop Java code into a Groovy script and it will just work as Java and Groovy share virtually the same syntax.

I tested this out with Eclipse. I created a quick Java version of “Hello World!”, copied and pasted the code into my Groovy project (commenting out the original code) and it worked!

Java code with Groovy - it works!

Java code with Groovy – it works!

This gives Groovy an additional advantage, as Java programmers will have a much less steep learning curve when the transition to Groovy.