I’m not quite certain what I think about Spring Roo, and I’m not sure whether it will become a mainstream java development tool, but I have to say it is damned interesting. It’s taken two rounds of playing with it, separated by months, and seeing Rod Johnson demo it last month, but I have a better idea of what it is.

The Roo site says that “Spring Roo is a next-generation rapid application development tool for Java developers. With Roo you can easily build full Java applications in minutes”. Rod Johnson described it as an effort to come up with a way to make Java programming less cumbersome, to prevent the JVM from become a legacy platform swept away by the newer generation of platforms like Ruby on Rails. So it is trying to achieve a similar goal to Grails, but in a dramatically different way.

I’ll take a stab at explaining what Roo is. It could be described as a round-tripping code generation tool. That is, you tell it what you want your domain model to be, and Roo generates the application code, including all of the scaffolding. The round-tripping part means that it’s not a one-way thing. You can edit and extend the code Roo generates, and Roo can still maintain the scaffolding, and even add scaffolding as you add, modify, and remove elements of your domain model.

So the phrase “code generation” sells Roo insultingly short. It doesn’t just generate code, it manages the scaffolding code dynamically as you work with your code.

What scaffolding does Roo manage? At the class level, it manages things like getters, setters, toString(), and the like. So you write your class file, add the fields, and the other bits are added behind the scenes. These are actually generated and managed in separate Aspect files. You can open and even edit these files, but editing them will break Roo’s model. But no worries, if you want to override the code that Roo generates, you can do so in your own class file. Override the setter, and you’re in charge. Annotations in your class file enable and disable Roo management, and often let you configure what Roo does. If you really need to change the way Roo handles some aspect of your classes, you can write a Roo plugin.

The upshot is that , but your class files are refreshingly clean, only containing the logic that really counts, and you’re still you’re pretty firmly in control of what happens.

At a higher level of scaffolding, Roo manages persistence and the interface, including the presentation layer and web services. Again, you have a high degree of control. You can specify which persistence framework you want to use - Hibernate, TopLink, etc. - and pretty much any database you’re likely to use.

The tradeoff for this is an interesting thing. The main price is that your application pretty much needs to follow the architecture and certain key design patterns that Roo uses. For example, persistence uses the Active Record pattern, with methods added to your domain classes, rather than DAO with separate DAO classes. You can disable this and write your own DAO’s, but the Roo folks make a good case for accepting that DAO’s are counter-productive with Roo applications.

In fact, the basic premise of Roo is that it will create applications using best practice patterns, and the latest mainstream Spring frameworks (Spring MVC, Webflow, Spring Security, etc.), and make it easy to keep your application up to date.

A corollary to this is that, unlike Grails, say, a Roo application is a “real” Java application, one that in theory you could have written without Roo, at least if you are the type of hyper-anal developer who makes a separate aspect file for the toString() method for each class.

Roo is not a tool for “dummies” who want to whip up an application without having to understand how Java, and the frameworks involved in creating a modern-day J2EE application, work. It can help an inexperienced developer create a simplistic application very quickly, but my guess is that a developer without a solid understanding of what’s happening under the hood will get stuck - or unstuck - pretty quickly.

It could be a helpful learning tool, or a crutch that prevents a developer from properly learning. For example I haven’t work worked with Tiles, but now I have a working Tiles application. I can hack around with the templates to customize my application, which might result in an application whose presentation is, well, hacky; or it might boost me up the Tiles learning curve. I suppose it really depends on me.

If Roo is not a tool for dummies, what it is is a tool for experienced Java and Spring developers to save time managing the scaffolding that we’ve come to take for granted in a J2EE application.

Roo is not a mature tool yet, but it is amazingly well engineered. It has pretty good basic documentation, including tutorials, which are enough to get going, and fairly good coverage of what it does. The reference section for the Roo commands is a bit thin, it doesn’t really give you enough of an idea of what each command is for, and why you might want to choose particular options.

Although some areas of Roo are pretty thoroughly implemented - the selection of databases, for example - others have limited options, such as implementing web services, or a plugin architecture for your own application. Roo itself does have a plugin architecture, so it seems likely that if it gains traction, it will gain much broader support for different types of applications.

But what there is of Roo is impressively solid stuff. The Roo shell’s content sensitive help and hint system is useful, and the way Roo dynamically handles changes you make within your code is pretty sweet. It’s just a slickly done tool that works the way you’d want it to.

The biggest barrier for adoption of Roo may be that it’s pretty much only for green field applications, or else applications which can be re-factored to follow the Roo application architecture. Again, the architecture of a Roo application needs to fit the Roo way, or you’ll probably end up fighting the tool, and a lot of team will probably resist this. But it has real potential to become a staple tool for Spring application developers.