Update: If you enjoy reading articles on programming or web development, please see our sister blog here: devblog.techhead.biz
Long before Guice, there was PicoContainer. I used to lurk the mailing lists of PicoContainer and the Avalon Framework project back in the day when Inversion of Control (IoC) was a relatively hot topic. (In fact, if you Google “Jonathan Hawkes” at this time, one of the very few mentions of me is one of my very few posts on the Avalon list.) However, this article is not intended to be an introduction to IoC.
PicoContainer is how I discovered Groovy.
Ant was at its hayday. XML was still somewhat of a buzzword (if it is not now). The folks at the NanoContainer project (PicoContainer’s big brother) made the (gasp) startling realization that all of the configuration files required by Avalon and the Spring framework were actually code. XML configuration files can be large and unwieldy. Learning all of the correct tags and attributes can be a more daunting task for a programmer than simply learning a new API. So why not just write configuration code in… well… code?
One reason is that it’s nice to be able to change configuration on the fly, or at least without a recompile. This is where Groovy comes in.
Groovy is a language for the Java VM. To call it a scripting language would be somewhat of a misnomer. Groovy produces Java bytecodes. It can call Java classes and be called by Java classes. However, like a scripting language, you can change it. You don't have to build it. (Unless you want your vanilla Java code to call it in a typesafe manner.)
Groovy essentially extends the syntax of Java. In most cases, valid Java code will be valid Groovy code. However, like a scripting language, Groovy does not force you to know the type of an object at “compile time”. It supports closures and lots of other little goodies.
Go check it out. If you are a Java programmer, you owe it to yourself.
