In my last post I commented that sometimes “drinking the Kool Aid” is a bad thing. Here’s an example that bit me for a couple of hours this week.

Groovy and Grails have done a lot to ‘make things work’ by expanding many of the core Java classes to remove the need for all the ‘work’ needed to get something to work. For example, database connections ‘just work’ and you don’t need tons of exception handling code or thinking about how to release them.

Groovy also makes interacting with existing Java code trivial.

However, the combination of the two leads to some problems. Consider my case. I wanted to upload a comma separated value (CSV) file in Grails, split the file apart and build objects from it. Pretty straight forward right? Done it many times in Java with Struts or GWT.

Searching for examples also showed a number of ways to do it. I took the ‘approved’ version from the Grails site.

Searching for ‘groovy csv’ also showed a lot of examples, including the use of CSVReader, which I’ve used before.

Putting the two examples together was trivial and took a few minutes to test and everything went perfect. Until I tried to upload the same file a second time to test the ‘update’ logic. I received an exception, because the file was locked on the host I couldn’t replace the ‘working’ copy.

Turns out that CSVReader is a Java class with very specific lifecycle steps that hadn’t been ‘groovy-fied’ yet. So while Groovy handled all the exception framework, collection logic etc, it didn’t know to close the CSVReader at the end. I added the explicit close() on CSVReader object and things work now.

I was (am?) trying to learn the Groovy paradigm, not just the language so I’m deliberately not writing ‘java in Groovy’. So I didn’t look at exceptions or lifecycle events since for a lot of other ‘common’ thinks Groovy just works. I’ll pay a little more attention to lifecycle from now on.

This is the first of hopefully several posts about my experiences and frustrations learning Groovy and Grails. I’ve been programming for over 20 years and have seen a lot of techniques, technologies and tools that claim to make a developer more productive. Many did make you more productive. Some did until you needed to modify the code a year later, or modify someone else’s code. So I’m pretty skeptical about all the claims from fan boys about any technology.

So with the hype around dynamic languages including Ruby and Groovy, I started looking into how useful they could be. For the record, when Bruce Tate talked about ruby at AJUG in August 2005 I was both skeptical and annoyed with what he was presenting. As a ‘fan boy’ he could see nothing wrong with Ruby or the impact it would have on a production system. In particular we got into a mini-debate about real costs of running a production server vs. benefits of Rails for faster development based on the runtime performance back then.

In November 2009, Pratik Patel did a Grails and Groovy presentation to AJUG, which was right after my NOSQL East presentation where I was asked why I don’t use Groovy instead of Java for my applications. Pratik’s presentation got me thinking more about Groovy and researching the differences and benefits from the Java world I’ve been working in for over 9 years now.

So, I’ve started my first Goovy/Grails project. I’ve been doing it part time for a couple of weeks and have some initial impressions.

Pros

• GORM for ORM hides a lot of the data tier and is pretty straightforward, especially if you’ve ever fought with understanding Hibernate. Some of the bizarre things are still there, but for the most part it understandable
• Auto creation of the UI and the scaffolding in Grails is impressive. After years of screwing up Struts and Tiles configurations and having no idea why, this is cool
• Being able to call down to Java as needed. I have A LOT of helper code and business logic that I don’t want to rewrite
• ‘duck typing’

Cons

• GORM. It took me most of a week and a lot of trial and error to figure out how to return certain fields from a multiple table query in a reporting interface without dropping into HSQL. (Yes, I plan on writing a post about this soon)
• Dynamic language support in tools. I use IntelliJ which is supposed to have the best Groovy/Grails support and it still sucks. I don’t want to wait until runtime to find out that I spelt a parameter name wrong. Or that a variable name is reserved word in Groovy (Category anyone?)
• Real examples. The IBM series is pretty good, but I spent a lot of time banging my head on file uploads and GORM beyond the basics.
  
• Are some of the ‘features’ really a step back? Naming parameters on method calls has been available since PL/1 (at least) and has always been a criticized as too verbose. It just 'feels' wrong to be using them
  

The biggest negative so far is drinking too much of the Kool Aid ;-) Grails/Groovy makes some things so simple that when you get outside what they’ve “groovy-fied” you need to think again like a Java programmer. I’ll give an example of this in my next post.

So far though I’m impressed with the language and the ease of doing things.

Video of my NoSQL East presentation

Here is the video from my NoSQL East presentation from last fall.

You can't hear the questions at the end so my answers sound strange ;-)