For those that don’t know, I’ve been working at a start-up called Carol, doing Groovy on Grails development. Groovy on Grails is a Java-based language and development framework which feels a lot like Ruby on Rails. The neat thing about it is that it can leverage existing Java code, which means it has access to the deepest and widest set of open source libraries on Earth. And if you happen to be in a Java shop and don’t have the resources to port it all to Ruby, but you’d like Rails-esque rapid development, then Grails may be the solution for you.
For the most part, the transition from doing commercial Java development to doing commercial Groovy development has been very smooth, and I’d most certainly rather do a web app in Groovy than in Java. There are, however, a few land mines to watch out for, and I decided to share some of those with the wider community.
Here’s one that just bit me.
There was an idiom in Java where people would use boolean variables to repreasent things with two states (mapping “true” and “false”), and Boolean variables to represent things with three states (mapping “null”, “true”, and “false”).
In Groovy, null is now false. So that idiom no longer works. And debugging that problem was non-trivial, because the code seemed to be working just fine. It even worked great if the route you expected to take was checked before the route it shouldn’t have taken. But if your else-if statements are in the wrong order, suddenly your code has very different behavior!
Related posts:
Pingback: Enfranchised Mind
Pingback: Enfranchised Mind » A Tricky Trap With Unit Test Mocks in Dynamic Languages