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.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Ben Alex  On September 20, 2010 at 23:49

    Hi Jason

    Glad you found today’s JavaOne session answered some of your open questions. We’ve also come a long way in terms of documentation since your earlier blog entry, so some of the questions are also addressed there.

    I’m looking forward to hearing how you go with Spring Roo on your next project.

    Best regards

    Ben Alex
    Project Lead, Spring Roo

  • Jason Sheedy  On October 3, 2010 at 18:10

    Hi Jason,
    Good post. I felt the same way about it at first, but have been warming up to it as I understand what’s going on a bit more. Still not 100% confident to take on a big project with it.

    The ITD’s are where all the real magic goes on, so I think the main rule of thumb it not to touch the ITD aspects generated by roo. Other than that I think you’re pretty safe to modify the tests, jsp’s, bean definitions, etc without any negative side effects. It definately takes some time to get your head around it all.

    Looking forward to hearing how you go with it too.

    Cheers,

    Jason

  • Sammy  On December 14, 2010 at 00:56

    I’ve basically had enough of roo and have no desire to keep trying with it in the short term nor associate my name with it any further in the workplace. For the productivity lost “playing with” roo, it’s delivered very little. The idea is great. The implementation, not so much. If it takes off and becomes the industry standard i will use it, but whether or not I like it will depend on how it evolves.

    I do agree that Ben Alex was very professional about responding to you. Whether or not I like using his frameworks, I’ll give him credit for that.

    In that vein, if you’ve changed your mind and are more positive about roo, can I suggest you link your previous post to this one. Given that a Google search for “roo sucks” returns your previous post as the number 1 hit. Without linking to the new one it looks like this is still your current opinion.

    • Jason  On December 14, 2010 at 07:02

      I’ve updated my previous post with links to the others I’ve written about as you suggested. I wouldn’t be so emphatic about Roo sucking anymore, but I still think it is of limited real-world utility. I really wish it was as awesome as it seems at first glance.

Trackbacks

  • By Spring Roo Sucks! « Jason Geeks Out! on December 14, 2010 at 07:00

    […] 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, […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: