Still talking about Spring Roo sucking

Back in June 2010, I wrote a provocative (apparently) post called Spring Roo Sucks! It was a bit of a rant, so I backed off on the tone, but I’m still defending the overall point.

Somebody commented that I had unfair expectations of this young project. I started to reply in the comments, but it got a little long-winded for a comment, so I’m putting it here.

Joseph wrote:

It’s a great project, your expectations are unreasonable because Spring roo doesn’t have release 2 or 3, but 1 … It’s a quite new project. And you expect it to be something that exist 4+ years and that has been extremely refactored in time…

If I was programming as a hobby, I might agree. But I need my tools to increase my productivity, no matter what revision.

There are plenty of smaller, less ambitious open source projects in version 0.9 that I have found to be extremely helpful. The issue is not the revision (Spring can bring a lot of resources to bear and they are working closely with Google on the GWT stuff). To me, the issue is with the scope. This tool builds a lot of my application, but it builds it exactly the way it wants to and with sensible defaults. But almost all interesting applications have something besides a CRUD view on a bunch of entities and as soon as you starting looking in the corners, you get lost. I don’t think it’s Roo’s fault exactly. It’s just the way code generation stuff works.

To me, there are similar issues with GUI drawing tools. Those are great and deliver a lot of productivity. Just lay out your screen the way you want it and presto! That works until you say, “actually, for these 5 fields, I only want to show each of them if the database says they should be visible and I want to adjust the size of the dialog accordingly, so I don’t have overflow and I don’t have a bunch of blank space.” So then you go look at all that code that got generated for you and you can pretty much understand most of it (or even all of it) but you start modifying that code to do more precisely what you want. So far, it’s still a productivity saver, but then someone says, “I want to change the theme” or “I want to add this button” and you say, “OK, that’s a few hours,” thinking you’ll impress them with your speed. Then they come back with “A day?!? How could it possibly take that long. You just open up the GUI builder and add the button!” But that doesn’t work anymore because the code isn’t code that the GUI builder understands anymore.

So, you’ve got code now that you basically understand even if it’s not structured as modularly as you would like, making future changes more expensive. You’ve also got some code that your mouse-jockey tool doesn’t recognize anymore, so you’re productivity boost from that was brief. However, I will concede that it was also substantial. You got a nice bootstrap to your project, so who’s complaining?

Not me, if it’s limited to the GUI – the outermost layer of your application on which nothing else is dependent. I don’t think it’s necessarily wise, though, to treat the foundation of your application (the domain model) and the glue (your controller layer or servlet layer or dialog layer or whatever you want to call it) the same way.

One other way Roo’s strategy is not as good a fit as GUI builders is that building a user interface is inherently visual and so is the tool. Moving stuff around to get it just so is what it’s all about. It’s a very visual exercise so a visual builder is just a good fit, even if you only get to use it for the first draft. Your domain model, however, doesn’t work quite that way. While you are building it at first, it is going to change several times as you realize this dependency would create a cycle or that field name doesn’t fit the naming convention that you really want or whatever. I find the Roo command line to be very unfriendly to this kind of refactoring work. That kind of work calls for an editor, not a command line.

As I’m writing this, I’m wondering to myself if you took the Roo command line away if I would like the tool better. You have to learn all the annotations, sure, but then you’ve learned them so you understand what you’re doing and how to change it. And you really would save yourself a ton of typing if you got good at it. So maybe in the near future I’ll come around on the annotations. We’ll see.

Comments

I am preparing for my talk about Spring Roo next week at Con-Fess in Vienna, thus I read some new blog entries about it.

The conclusion of my talk will contain some of your critics (although I really like Spring Roo)…

Spring Roo is great for CRUD applications. I recommend it because of a good community and a powerful vendor (compared to other CRUD frameworks such as Roma Meta Framework or OpenXava).
Personally, I would prefer Grails, but if you want to create CRUD with Java, then Spring Roo is the best alternative.

Spring Roo is also good for learning technologies (JPA, Spring, GAE, many more), because you get a working example in seconds, and you can create more complex stuff within minutes using the Roo Shell. Then you can learn and understand how Spring Roo uses these technologies.

But if you want to build something more complex, then you should choose something else, because Spring Roo will create more questions than answers.

I agree with you regarding the Roo Shell: Often, it is easier to use the annotations, in my opinion. The Roo Shell is great for some stuff such as create the persistence setup or scaffolding. But it is awkward for some other stuff such as adding an entity or even worse, an attribute to an entity.

My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else…

Support for GWT in Spring Roo is still beta-release quality at best even in release 1.2.2. But that does not make Roo suck. Web MVC support is decent. It looks like a lot of frustration with Roo comes from oversized expectations rather than Roo’s quality. You can look it at as a tool for building relatively simple CRUD apps, with or without a web service layer, or web service apps for an SOA system, which is how we use it, and it works great for us, saving a lot of dev time. There is a lot of focus on the web interface limitations, but Roo is not a web framework, you dont even have to have a UI in Roo apps… Bottom line, If you are building next Amazon or Facebook – Roo is not going to be a foundation of your app’s implementation, but for something like a customer management app, or a bunch of small services within SOA -it is a great productivity enhancement tool!

Also, regarding refactoring domain model using command line tooI – I do not believe the Roo team ever said anywhere that you should use only roo shell to create or modify your application, in fact they went to great lenghts to make sure you can switch back and forth between command line and IDE, and changes in your code would be immediately recognized by theother tool. We have built several apps this way even without using STS – just roo shell and Eclipse,and this approach works. Of course, Roo is not the silver bullet ,you just have to realize and lower expectations, it is a great productivity enhancement tool for a specific niche, for a type of applications where you mostly need CRUD UI,but a rich domain model with potentially complex business logic and/or a web service interface. If you adopt SOA – Roo can become the foundation technology for building your web services.