In the last few years I’ve been exposed to a huge variety of different tools and frameworks, and have followed the transition of Java from 1.4 to 1.6(and beyond!) Past time to take a look at just what has changed, and perhaps why it doesn’t matter so much.

Build tools and dependency management – Ant, Maven, Ivy, Grape

I started off in my programming career with lots of  build.xml files and eventually made the (at times rough) transition from there to pom.xml. The best part of this: never having to hand-code a classpath again. Worth it right there. Maven adds enough dependency management magic to the build process to make it a nice alternative, and when you factor in the great IDE support available(I’m looking at you IntelliJ) it’s almost a no brainer. When you need to switch from one project to another, as has been pretty common in my career at least, being able to open a project at first sight and have your IDE correctly load up and run out of the box is a big plus.

Of late I’ve been getting more experience with Grape and Ivy. These dependency management tools bring some really elegant simplicity to the table, especially Grape; good-bye to complicated command line “java -cp …” calls when all you want to do is run a little snippet locally and import a jar. Now of course, this journey takes us all the way back to ant, since it is such a close(and apparently integral) part of Ivy. Which is all right in my book – ant has really stepped up to the challenge in recent history, in no small part due to the community. The Groovy AntBuilder and Gant enable many of the iterative style features so hard to express in xml mostly trivial, greatly simplifying usage of the powerful ant capabilities and making them easier to bring to bear. Now of course, the ability to run both Groovy and ant from with Maven kind of make it a moot point – if you really want to make your life easy, it pays to get to know all of these technologies and fit them into your build in the most effective way possible.

Dependency Injection – Spring, Maven, Seam, Guice

First time I saw dependency injection in action was with Spring. The IOC principle has since then become central to how I look at software. I mean, if you want to unit test effectively, it’s pretty much compulsory. And it encourages you away from ‘bad’ design patterns – static method only classes, shared instantiated utility classes, lack of interface abstraction, etc.

Maven and the Plexus container makes writing Maven plugins a breeze. Baking functionality into a maven build is really pretty trivial and I have had a lot of success with GMaven plugins for applying static analysis to a build: verifying that all properties in a resource bundle are actually referenced in a web application for instance. It’s an added bonus that you can easily test your plugin for Maven… with Maven.

The Seam framework also provides a very nice IOC container and it has been a real pleasure to leverage that power in a real-world application. It certainly facillitates testing – my preferred stack is TestNG with Unitils to add easy annotation support. It’s the simple things like @TestedObject to clearly specify intent and @InjectInto to mock out dependencies that make testing outside of the container as painless as possible. Not only does it ease testing, it encourages good modularization of functionality.

Guice is comparatively the new kid on the block, and the dependency injection framework I have the least experience with, but again the idea is sound, and having another implementation that can take advantage of history is a good thing. Webbeans aims to take the paradigm to the next level, and it will be interesting to see how that implementation evolves. Anyway you want to cut it, the picture is pretty clear – don’t hardcode your dependencies – inject them!

I am a… Functional Programmer?

Somehow, since I started writing code – I started to get it! Closures now make sense to me, currying does not sound like a cooking technique and I realized that however you code certain fundamentals apply.

• write the code
• test the hell out of the code
• make sure the code gets USED, because this is the only way you’re going to find the bugs you didn’t think of in your tests(*see one line above). And no, you didn’t think of everything one line above.

The real point here is don’t discriminate – use the right tools for the job and get the most out of them you can, whether it’s functional VS procedural, Ant VS Maven, etc ad infinitum. Each tool brings a slightly different skillset to the table and if you want to make your programming life easier, it does pay to know which to use when (and how much). Beyond that, taking the time to pry and prod at the tools you use challenges your assumptions and gives you a greater appreciation of just exactly what is ‘going on’ when you hit the Big Green Go button on your build.
Not to mention that all of the tools/frameworks I’ve described here have LOTS of daily users AND represent some of the most executed(and IMO best written) code out there in the Java+ community. As a developer, you can’t help but benefit from digging into such code.
Whatever you do, don’t stay stuck in the past. It just doesn’t make a whole lot of sense when what you’re really after is to make your job as easy and painless as possible to do.

Related posts:

1. Groovy and Bash – can scripting get much easier?
2. Groovy and Glazed Lists with Grape
3. Griffon support in latest Intellij EAP

So what does Groovy add to the mix to make it an attractive option on top of(or instead of) bash on its own? Dependency management, lean distribution and testability all jump to mind.

Dependency Management

Grape gives you the same stability that Maven provides. Any script can load any Java library is wants to utilize into the classpath at runtime using your existing repository or an available internet connection.

Lean Distribution

Because Grape utilizes a central repository, all dependencies are shared across the entire system. Scripts with extremely small footprints can do some pretty big things. Recently I’ve seen examples of parsing html using TagSoup(I swear I originally saw that example somewhere else but for the life of me can’t find it now), Apache Camel integration(and again) and even spawning a local HSQL database, complete with Hibernate. Within a very sparse number of lines, you can do more than you could ever imagine with plain Java, and I’m more than willing to admit that I wouldn’t know where to start with bash to do any of the stuff I just mentioned.

Testability

The only thing that separates a stand-alone Groovy script from a Groovy class on the command line is the #!. If you’re willing to launch the script on the command line explicitly using the ‘groovy’ executable you can abandon that. So now the difference becomes ‘./groovyScript’ versus ‘groovy groovyScript’. But…. that same script is now ripe and ready to be included in the test framework you use everyday for regular project development. You can easily compose it into unit-testable methods and treat it like any other part of a large and rapidly evolving software project – things that I’ve always found inherently difficult with a command line script. Mostly I find that the truly useful scripts and snippets – the ones that are used regularly by developers on a day to day basis – are the ones that also never end up under source control, and don’t get the benefit of evolutionary change that most code gets.

Building upon the example included in the InfoQ Groovy 1.6 launch notice, here’s the quick and dirty addition of a JXTable component for showing the results of parsing all links from an html page with TagSoup. A text field is used to bind the url and a click of the button starts it off. It’s not pretty, but it did take less than 10 minutes to do so judge for yourself. Run this script from the command line using the groovy command (V1.6+).

import org.jdesktop.swingx.JXTable
import javax.swing.*

@Grab(group='org.swinglabs', module='swingx', version='0.9.3')
@Grab(group='org.ccil.cowan.tagsoup', module='tagsoup', version='0.9.7')
def getHtml(url) {
       def parser = new XmlParser(new org.ccil.cowan.tagsoup.Parser())
       parser.parse(url)
}
def data = [ ]

def my = groovy.swing.SwingBuilder.build {
       frame = frame(title:'Groovy Grab Test', size:[800,500], show:true, pack:true, defaultCloseOperation: WindowConstants.DISPOSE_ON_CLOSE) {
       actions(){
             action(name:'Fetch', id:'fetchAction')
             {
                   data.clear
                   getHtml(urlField.text).body.'**'.a.@href.each{ data << [url:it] }
                   frame.repaint()
             }
       }
       boxLayout(axis: BoxLayout.Y_AXIS)
       scrollPane() {
             myTable = table(new JXTable(columnControlVisible:true)){
                   tableModel(list:data){
                   propertyColumn(header: 'URL', propertyName: 'url')
             }
       }
 }
       textField(id:'urlField')
       button(fetchAction)
 }
}

Since I work for an organization that uses maven extensively for dependency management, most of the libraries that come to mind as handy bash replacements are already available in my local repository. Apache commons, Google collections, and most importantly – any libraries that are specifically dealing with your own products – all are at your fingertips! Even better, since most of the tasks that commonly fall to scripting are pretty low level (moving files around, etc), there are easy alternatives.

AntBuilder, for instance, is baked into Groovy, and provides a great abstraction around most of the desired functionality you want in a scripting environment. Moving files, doing text replacement,tarring files, sending mail – anything that Apache Ant can do, AntBuilder can do. But without all of that infuriating and frustating xml. An example(complete with exception handling!) courtesy of Andrew Glover, in this article.

ant = new AntBuilder()
ant.mkdir(dir:"/dev/projects/ighr/binaries/")

try{
       ant.javac(srcdir:"/dev/projects/ighr/src",
       destdir:"/dev/projects/ighr/binaries/" )

}catch(Throwable thr){
       ant.mail(mailhost:"mail.anywhere.com", subject:"build failure"){
             from(address:"buildmaster@anywhere.com", name:"buildmaster")
             to(address:"dev-team@anywhere.com", name:"Development Team")
             message("Unable to compile ighr's source.")
       }
}

Where you REALLY need it, you of course are still able to call on any and all of the *nix powertools you might like in a Groovy script. Personally, more and more I find that building and testing the script in my chosen IDE, and using the libraries I’m most comfortable with to do it, is a much more productive and enjoyable experience.

P.S. Gotta apologize about the code formatting – if anyone knows a wordpress syntax highlighting plugin that DOESN’T blow away your formatting or randomly replace the text with html entities, gimme a shout please!

Related posts:

1. Griffon bash completion…
2. Using the TestNG DataProvider with Groovy
3. Groovy and Hibernate Validator for Dynamic Constraints