I Roo the day…

I am currently starting a fairly simple Java CRUD web application for work and at the same time I’ve been playing with developing a simple web application in Clojure.

In order to develop the app for work I wanted something I could use to drive out a prototype quickly but then enhance and augment further. So I took a quick look at Spring Roo.

I found I could generate the basics of a CRUD app in hours, including security, etc. Great…or was it?

I found myself unsettled by a number of things in Roo.

• Automatically generated integration tests work well in Roo but I found it hard to find good examples of simple extensions to the generated integration tests. For example, how to test a constraint like @DecimalMax on a JPA entity field.
• I always run my integration tests against a different database in the ‘test’ phase of the build than the database configured for the ‘package’ phase. Usually this is to allow tests to run against an in memory database so they can run fast, clean and without a database server running. This is not something Roo helps you with, and although I’ve done this in Spring and could use the same Spring configuration for the Roo project it’s not obvious or easy how to do this. I just expected it to be something the Roo would support out of the box.
• I am a TDD addict…Roo does not support TDD at all well. It’s possible but not natural.
• Although Roo generates nice clean classes with little boilerplate code as it’s still Java it felt unnerving like magic…I didn’t trust it. I kept having to look at the generated AspectJ to check.
• I always set up my continuous integration server (Jenkins) and maven builds to run code coverage and static code analysis tools (I’m using Sonar this time). As the Java code generated by Roo is minimal, with the aspects adding the bulk of the methods you get a lot of static analysis rules failing (due to rules like, “Unused private field”).
• You also get low branch coverage messages that don’t equate to any code in source files. I suspect that this is referencing code that has been aspected onto the class.
• It still felt verbose and heavy weight compared with Clojure code…just look at the number of jars a simple Roo project requires!

Maybe I’m being spoiled by Clojure but it all felt a bit clunky and too much wasn’t apparent or transparent enough. Having said that, Spring Roo cuts out a lot of set up time. Especially for getting a simple CRUD type web application up fast. If, like me, you have to live in the Java world due to skill sets in your organisation/client then it’s a good start.

You can always push the generated Aspect code back into your Java source if the ‘stuff happens by magic’ feeling keeps unnerving you. I did get used to this within a few days though.

So, overall I’m going to use Roo for prototyping and simple CRUD type applications but really I feel that Groovy/Grails, Scala or Clojure give you more, more transparently. You just need to ‘invest’ in learning them.