April 22, 2019
Hot Topics:

Groovy Development

  • September 15, 2005
  • By Dick Wall
  • Send Email »
  • More Articles »

About this Article

Unlike many of my previous articles, I decided not to make this a click-along. There is so much to talk about in the Groovy language that I did not want to get too sidetracked in explaining the SQL database setup, or creating a framework to demonstrate it all.

I can tell you, however, that this information is based on my own experience constructing such a framework for a project at work. We needed a quick and easy way to construct translators (importers and exporters, if you prefer) for getting data in and out of a database schema. In many cases, the export (or import) was to (or from) an XML file.

We could have used any number of pre-written XML tools for this purpose; for example, Oracle (the database in question in this case) has a number of XML processing options to easily get data in and out of a database, and there are many other options that have similar functionality. In the case of Oracle's own tool, we wanted more database agnosticism. As for the other tools? Well, in the translators for this project, it was not simply case of mapping XML data straight into a waiting database schema. For one thing, the schema did not always resemble the XML data being imported (or exported). For another, there were numerous business rules used to calculate still more database or XML data.

To illustrate, the system constructed was a workflow system that interfaced with external agencies using various XML formats. Using the data in the database, an XML schedule file was formed and sent out to the company members, who would then examine it and provide a response, also in XML. The response had some identifying information relating to the data originally sent out, and then could contain a number of different responses. For one, a problem with the data could be signaled, and it might be specific to a certain series in the outgoing schedule, or even an individual value. For another, our system needed a certain "response code" field to be set based on the response data code in combination with the anomalies signaled.

For example, if the response code is G29, and one of the data series is marked as having inconsistent values, our response code is -210. Otherwise, if G29 is marked, but no data is identified as problematic, set the response code to -200 (really, these are made-up numbers, but hopefully they show the kind of business rule that was needed).

So, we are faced with the possibility of using a simple and fast mapping tool to get the data in, and then doing a separate post-processing step to apply all of the business logic, or of using a more sophisticated language for the whole process, with Java being high on the list because the rest of the application is already written in Java.

What Is Groovy?

Around the same time we were looking at this problem, I was following the development of a new language called Groovy (a name that is the language's worst enemy, in my opinion, because I was the one who had to pitch the use of something called "Groovy" to write our translation engine and it was a hard sell because of the name alone). Groovy also can be referred to as JSR-241, which is far more boring, but also much more acceptable in a corporate setting.

Groovy is a scripting language that is largely compatible with Java syntax. (And when I say that, I mean that there are very few things you can write in Java that will break Groovy, one curious and notable exception being the for loop that has been simplified.) You can either interpret or compile Groovy, and compiled Groovy code can be packaged up into jars that look just like Java code, but will run slower than Java.

Why Use Groovy?

So, if the language has such similar syntax to Java and is slower, why not just use Java? Well, just because Groovy can understand straight Java code, it doesn't mean that is all it can understand. Normal Java requires a lot of strong typing and compile time checking that mean that (unless you use reflection) many of the neat shortcuts that dynamic scripting languages are hard or require a lot of extra code (like reflection code).

Although Groovy will compile strongly typed code quite happily, you can also drop the typing, so that something like:

myStr = "Hello world";

can become

myStr = "Hello world";

Also, a method definition like:

public int myMethod(boolean flag, String greeting, double mult) {

can become

def myMethod(flag, greeting, mult) {

Also, things such as loops have been simplified a great deal:

for(int i=0; i<100; i++) {


for (i in 0..99) {

Ok, so nothing earth shattering so far, but Groovy doesn't stop there. For one thing, it has all sorts of shorthand syntax that saves a lot of time. Some examples (but not all by far) include:

  • Native list and map syntax
  • Closures (you can think of a closure very loosely as a method with no name or formal definition—a code block, if you prefer)
  • Excellent iteration syntax ( list.each(), for (i in 1..10) )
  • Incredibly concise XML and SQL syntax support, including Markup

All of these features will be covered in this article, but it is this last point that really convinced me to to try Groovy for our translators. As it turned out, it was a very good choice.

Getting Groovy

OK, before going any further, you may be wondering where you can find Groovy.

Groovy's home is http://groovy.codehaus.org/, and the latest version can be found at http://dist.codehaus.org/groovy/distributions/?M=D (the link is already sorted with most recent at the top).

Installation is easy; just choose the gz or zip file (depending on your preference—note also that you can pick up the src distros if you want to; but to start with, grab one that does not have src in the name) and unpack it onto your machine somewhere. I then recommend adding the bin directory to your PATH environment variable so that the machine can execute the compiler and shells. Try it from the command line by typing groovysh; you should see something like this:

Lets get Groovy!
Version: 1.0-jsr-03 JVM: 1.4.2_06-b03
Type 'exit' to terminate the shell
Type 'help' for command help
Type 'go' to execute the statements

Type exit to get out of it—you are ready to go Groovy.

The Console and JEdit

Groovy has a very useful tool, called the Groovy Console, that comes with it. You can start it by typing GroovyConsole at the command line and you should see a window come up with an upper and a lower pane. The upper pane can be used to type in Groovy code to try out, and the bottom pane is the groovy shell and shows execution traces. Note that any output to standard out or standard error will go not to the bottom pane, but to the standard output in the command line window.

The Groovy console is extremely useful. If you are trying to develop some snippet of useful, Groovy code, this is the place to do it. Once you have edited the code you want to run, just go to the Actions menu and select Run. It will either run the code snippet, or explain to you why it couldn't. It's very basic compared with a full Java IDE, but it is very useful to just try out some ideas.

Click here for a larger image.

In this example, you have some code that could be Java (except from the test part not needing to be enclosed in a public static void main() construct). If you run it, you should see "Hello Dr. Livingstone" written to the standard output in the command line you called GroovyConsole from.

I would also like to mention JEdit here; if you have never used JEdit, I strongly recommend it. You can download it from http://www.jedit.org/ and it has Groovy syntax coloring. Again, this is a far cry from a full IDE environment but those will be improved over time. In the meantime, I tend to use either JEdit or NetBeans with the Groovy plugin available from https://coyote.dev.java.net/ and there is also an Eclipse plugin for Groovy available at http://groovy.codehaus.org/Eclipse+Plugin.

Moving on to the real meat of the article... As a Groovy neophyte, the first problem I found was that the documentation is a bit sparse at the moment. It is for this reason that I want to delve into at least those features of the language that I found useful for the translators I wrote, in the hope that it will provide a starting point for people and give them a bit of a leg up. I am sure there will be holes because I treat Groovy like most other things I deal with on a daily basis—a tool to solve a problem, and often once I have solved the problem, I move on to the next problem and come back to the tool later.

Page 1 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date