Category Archives: Spring

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.

Another Look at Roo

OK, so I attended the Roo session today at JavaOne.  I got frustrated with it before and I’m more cynical than I started out, but that Ben Alex is just so darned earnest you can’t help but root for the guy.  Not to mention that it’s worth rooting for the tool to be successful just to make my life easier.

I was pretty harsh on Roo before.  I conceded that it still had promise, but I was very disappointed in the experience past the initial euphoria that comes with such a rapid development.  The great thing about the tool (and others like it) is that it basically builds an application for you with very little effort.  The problem can be right after that.  So far in my experience, it happens without fail.

The application that it builds for you is not quite the application you want – just most of it.  That’s great, right? If it builds 80% of the application you only need to build the other 20%.  Unfortunately, it doesn’t quite work that way.  The 80% that’s built is full of stuff you don’t understand (because it was auto-generated). When I say hard to understand, I don’t just mean that the code is hard to read (it often is) or that it uses a bunch of techniques that are unfamiliar to mortal developers (that’s usually true, too).  It’s also that it is unclear how to extend it.

So Roo generates all this persistence stuff that I like, and I like the controller scaffolding, but not the jspx files.  Can I delete them? Will the tool complain? If the tool doesn’t complain, will something else complain when try to start the server and they aren’t there? What files are safe to edit, what files should not be touched and what files can be edited with care? What about all those AspectJ files? It doesn’t look like the autogenerated test does anything, but I can see that it’s running 9 tests. What is it doing, exactly? I dunno – can’t see the code.

If you can’t figure that stuff out, you’re stuck with 80% of an application that can’t be finished so you’re pretty close to 0% of the way to a finished application.

I left with more hope than when I entered.  I got some clarification on some of those questions in my session today.  It is also perfectly valid to use Roo to build 80% of your application and then remove Roo.  Now you can edit whatever you like – it’s just Java.  You can’t remove Roo automatically, but you can do it manually without too much effort.  Now I’ve got a huge leg up on building my application.

It’s too late for my current project, but my next project will get going soon and I’m going to give Roo another day in court (the GWT stuff still might not be ready for prime time).  It’s cheap to try.

Spring Roo Rocks!

OK, that overstates it a bit for me, but consider it kind of a make-up call for my overstating my previous objections.  However, a couple things I think are awesome:

  • After posting about Roo sucking, Ben Alex, founder and lead for the Roo project himself, got back to me to address some of my concerns.
  • I thought there were some “not ready for prime-time” problems and some fundamental problems.  Ben, who is way smarter than me, took the time to explain how some of my “fundamental” problems had potential solutions.  Now, these things aren’t solved yet, but they’re on the roadmap and they’re not insurmountable as I first thought.

I am very impressed that the project lead cares enough about gripes from unknown developers out here that he took the time to respond personally.  That bumps the whole project up in my book.  It’s still not in a state where I can use it for myself, so maybe this post should be “Ben Alex Rocks!”, but it had exciting potential to really increase productivity before I tried to use and it has exciting potential again.  I’ll be watching carefully.

Spring Roo Sucks!

I’ve been trying out Spring Roo and the first pass was very impressive and exciting. I created a domain model with persistence lickety-split with integration tests to boot! Seriously, like 30 minutes.

Then I created a default web application – neato! It’s certainly not the web application I would deliver as final, but there’s a lot set up for you there and it worked.

Then I went and started changing my entities – adding fields, overriding toString, etc… works great! OK, I didn’t like my package structure because I had all my domain objects in the same package. Let’s create some new packages and move stuff around using Eclipse refactoring… oops! Now there are some errors in my AspectJ configuration stuff. Too bad I haven’t really learned AspectJ except the broad strokes, so I don’t really know what’s going on. I manage to find a configuration file with references to the old classes in their old packages. I remove those references and things are working again… not too bad. The honeymoon isn’t over but we’re packing our bags to check out of the hotel.

Then I decided I wanted to try GWT instead of Spring MVC. Both are supported, so it should be easy, right? Well, guess again.

I couldn’t figure out (at least in a short amount of time) how to undo the Spring MVC stuff. Well, that shouldn’t be that big a deal. Since most of the code in the domain layer is auto-generated anyway, I’ll just create a new project and copy the relevant entity files over and start again from there. That was troublesome for reasons I can’t explain, probably my fault, but I got through it. Now, before I run ‘setup gwt’ I decide I don’t want to have this back out problem again, so I’ll put all of my domain stuff in a maven module. Then I can create my gwt module and just add the dependency, right? No, that’s not possible, since all the Roo annotations are only available at compile time, they’re not in the bytecode, so the gwt stuff has to be in the same maven module.

So punt on that idea and just run ‘setup gwt’ in the same project. Oops – some of my entities have one to many relationships represented by a Set, but that’s not supported yet so I’m getting compile errors. That may be just because it’s an early release version, but it’s a pretty big problem.

OK, so GWT (and probably Spring MVC) are not ready for prime time and maybe never will be for multi-module projects, but it’s still pretty useful for the domain model, right. I’ll just create a module for my domain (as long as your domain is in one module) and just hand-code GWT like we all had to do before Roo. Well, no. It turns out Roo is not very interested in supporting multi-module projects at all, including just specifying a parent in the pom.

In summary:

  • Roo generates “stock-standard Java”, but it turns out that, like most automated code generation tools before it, it’s very obtuse and easy to edit it in ways that mess up the round-tripping.
  • Roo only good (if it’s good at all) for single, monolithic maven projects.
  • Roo + GWT is only good for simple demos.
  • It’s going to make me look bad because after trying my initial toy project, I promised a larger project in a short amount of time that is going to be impossible to deliver.
  • It made me feel stupid because I should have known better.  There are no free rides.  (How many times must I relearn this lesson?)
  • Roo is only three letters and makes a bad Twitter hashtag.
  • Roo is a stupid name.

Update 12/14/10:

This does not represent my full opinion on the subject as I have related subsequent posts on the subject here and here.  The tentative conclusion I have made is that I still can’t use it, but that, hypothetically, it could be used to bootstrap a project, then pull all the Roo annotations out.  For that to be worthwhile, you (and those who contribute to your code) would need to know your way around AspectJ and you would need to have a pretty good idea of your application up front.  If you used it just for a bare bones toy version of the application, I’m not sure the effort of pulling the annotations out will make up for the requirement to use exactly the techniques Roo picked for you in the first place.