I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Spring Roo: The Answer To Real Rapid Application Development?

03.05.2010
| 23409 views |
  • submit to reddit

At the very end of 2009, Spring Roo GA was released, providing Java enterprise developers with a huge productivity boost. Similar in philosophy to Ruby on Rails, and with upcoming Flex & GWT support, Spring Roo could be the most significant new development tool for the Java community. In this article, I'll give a quick introduction to Roo, as well as speaking with it's creator, Ben Alex, about it's exciting future. 

What is Spring Roo All About?

Spring Roo is a development time tool that provides ongoing productivity in Java. While other tools give you that initial jumpstart, and then leave you to do the rest yourself, Roo continues to sit alongside the developer  for the entire application lifecycle, continuing to look after parts of the application for you.

Roo's mission is to fundamentally and sustainably improve Java developer productivity without compromising engineering integrity or flexibility.

Roo could be compared with Ruby On Rails. Both aim to provide productivity in the building of request-response web applications. Roo has a similar approach to Rails have an active persistance pattern. In Roo,  persistance methods are put inside the entities, which means that an object is provided with methods such as findByID or remove. There's no need to do any persistance related configuration. The full lifecycle, from an empty directory to deploying on a server, is enabled in Roo.

As Roo runs on the JVM it has a lot of performance characteristics: there's no engineering tradeoff in using Roo. Unlike a lot of other applications, you don't have a lot of refactoring to do by removing Roo. You also don't get any extra CPU time or memory consumption at runtime.  Roo has no technology lock-in, no impact on performance and no additional memory consumption. 

We believe Roo fills a very sweet spot between the power of existing IDEs, the productivity potential demonstrated by modern web RAD frameworks, and the deep desire for Java developers to have a tool that works the way they want to work and reflect the engineering principles that they value. This has resulted in a non-invasive background tool that is exceptionally easy to learn how to use, can be applied to both existing and new projects, and streamlines the development of world best practise applications at extraordinary speed.

Roo has a really easy to use shell for getting your application together. In fact, Roo's author claims that you can get an application built in 10 minutes. We've embedded the tutorial video here so that you can see how easy it really is. There's no programming in this 10 minute test, it's all interaction with the Roo shell.

The Spring Roo site has a useful reference guide that brings you through further customization of your web application such as editing JSPs and changing the look & feel.




 

And now, onto my interview with Ben Alex,the man behind the technology.

James: Is Roo just intended for server-side application development?

Ben: Roo is used to create server side enterprise applications. Spring Roo has the same key features that an IDE has, without aiming to be an IDE. It is only used at development time, so when you roll out the application you developed with Roo, there's no evidence that you used it in the application creation, just as when you build an application using Netbeans or SpringSource Tool Suite.

We started by building MVC request-response applications. We're currently working on support for client-side applications, with a focus on Flex and Google Web Toolkit in the next version of Roo.

James: When will we see a version for these type of client-side applications?

Ben: You can try it off the trunk right now, we haven't shipped a version of this yet. We're working on a downloadable, usable version of Roo that will build a GWT application for the second quarter of 2010. Automated the building of Flex and GWT applications will be a huge benefit to Java developers.

Also, in Q1 we want to add support for  database introspection, so you can get Roo to turn your existing database into a webapp. We're also making it easier, and much more elegant to write the JSP pages.


James: What is the output of a Roo application?

Ben: With Roo, we asked how could we build a framework with the fewest barriers to adoption. First of all you'd need to be able to program in Java. Secondly, we wanted to be able to use all the technologies and standards that are ubiquitous, like the Maven build system. So, when you use Roo, it'll set up Maven correctly for you. About 75% of enterprise applications that we surveyed use Maven, so developers using Roo get the added benefits of using Maven. Similarly, we use Spring and so on for all the major technologies. The same technologies that have been behind their applications up to now are in use with Roo.

The adoption barrier is next to nothing, as there is no abstractions on top of the common technologies, using them in their native form. And there's no lock-in: you can remove Roo from your project in about 3 minutes if you decide you don't need Roo anymore.

(The following Wikipedia entry shows the list of technologies that Roo supports out of the box)

James: Can you give a bit of history into the evolution of Spring Roo? 

Ben: Back in 2005, I was building a lot of applications, and all of these apps were doing the same thing. I thought it was quite tedious, so I put together a tool to help me out. We never released it, but I showed the tool at a couple of conferences and people were quite excited about what it could do. I was busy doing other things at the time, I started the Australian subsidiary of SpringSource, and I was leading Spring Security.

Towards the end of 2008, I picked it up again and did a prototype. I showed it to a few colleagues at SpringOne that year, and they all loved it. For the first four months of 2009 I worked full time on Roo, after it had been approved as a project. In April 2009 we made it available in alpha form for people to download and try out. After a series of development releases, Spring Roo GA was released on Dec 31 2009.

(You can read a more detailed history in the Spring Roo project documentation)

James: Why isn't there a bigger fuss about Spring Roo? It seems deserving of more attention?

Ben: We're seeing a lot of feedback, and it's showing up at a lot of conferences. It's very popular on the Spring Framework community site forum. I'm happy for it not to snowball out of control just yet, at least until we release Spring Roo 1.1, where the request-response MVC features will be much better.

One of the challenges for frameworks like Roo, is that people who program in Java already have their own ways of doing things. So when new tools come along, they provide an improvement, but it takes a while to capture the imagination. If it was written in Clojure there would be a big fuss, as it's one of the latest trends. But as it's written in Java, that makes it's adoption in the enterprise easier, as that's what people are writing their web applications in right now - proven and approved technologies. The
list of technologies that we mentioned earlier contains the dominiant technologies in the Java space.

James: I really like that it's all built around Java. After investing so much time in Java, it's comforting to see that you've taken that approach.

Ben: That philosophy is unbelievably frequent, people are interesting in new technologies, but everyone generally has a day job and want to be productive with the things that they've spent time learning. And as you're editing the application, because you're using mature, standard Java technologies, it's easy to find your way around any problems that might come up.

Coming up Next: I'll be taking the ten minute test with the latest release of Roo and will be taking a look at what's new.

Comments

JeffS replied on Fri, 2010/03/05 - 12:26pm

I tried the Spring Roo tutorial last week using the SpringSource Tool Suite, and was very very very impressed. I literally did have a working web app, with domain objects and entities and servlets and JSPs, Aspects, and of course Spring with Hibernate, up and running on the Spring dm Server within about 10 minutes (give or take a minute or two). This was always one of my beefs with Spring and things Spring related - it would just take a lot of tedious work to get Spring app up and running - setting things up, configuring, wiring things together, etc. Now, one of the most powerful, fast, light, flexible enterprise component frameworks (Spring), is being combined with Rails-like or Grails-like high productivity (Spring Roo). Really really good stuff.

Dan Haywood replied on Sat, 2010/03/06 - 2:25pm

Is Roo anything more than a code generator?  My problem with code generators is that you still end up with a bunch of artifacts to have to maintain.  It's all well and good to be able to generate a bunch of stuff quickly, but enterprise apps don't live for 10 mins, they live for years.  Perhaps Roo is more than this, though?

Slim Ouertani replied on Sat, 2010/03/06 - 4:09pm

I have presented this year spring roo, a the audiance are very motivated as we use AndroMda and this tool is very old ;) with no possibility to change code generated and you ba salve of AndroMda and xmi files.

 

Keep in mind that we don't need modeling  but we need production! This is the roo answer.

Mrmagoo Magoo replied on Sun, 2010/03/07 - 1:30am in response to: Dan Haywood

You really need to read up on it.

The summary is that it uses proper AOP and very well managed file system to allow you to remove Roo at any stage by inlining the AOP code. This code is SEPERATE otherwise and does not pollute you own code and requires little if any management by you. It also uses best practice patterns so the code is hopefully not incongruent with how you would have structured things anyway.

So yes it is a LOT more than this. I would suggest downloading the special eclipse version designed for roo to test it out. It gives you a better overview of how the projects are structured and you can just delete the whole eclipse dir and workspace when you are done without affecting your normal environment.

Remembering of course that this sort of thing is always a trade off. (what isn't?!) There has to be sacrifices at some level if you are pedantic enough. :) However I think roo is approaching a silver bullet for java on this. I mean this mainly in terms of where I see it going in the next few years rather than the brand spanking new version it has now. (only fools would be that short sighted)

What can I say? You have done it again Spring. :) Something to be excited about.

Dhaval Nagar replied on Sun, 2010/03/07 - 3:53am

@mrshanepaul yes is very well designed and maintains the non-intrusiveness as it says.

One can remove the Roo/AOP part from the entire project and run it like a normal java web application in any IDE. I have written a small article to run Roo apps in NetBeans at Roo with NetBeans

Justin Forder replied on Sun, 2010/03/07 - 3:44pm

@Dan - Roo isn't just a one-time code generator. It has a shell from which you can use Roo commands to create projects, entities, fields etc. The Java classes it creates have Roo annotations, and Roo uses these to take care of the associated 'accidental complexity' e.g. getters/setters, toString and persistence support. It puts these in separate AspectJ aspects, so the code you work on is just the essentials plus a few annotations. While the Roo shell is running it watches your .java files for changes and makes corresponding changes in its .aj files. Or you can edit for a while without Roo running - when you run Roo again it will catch up with the changes you have made.

The Roo annotations are not retained at runtime, the code Roo generates has no run-time dependencies on Roo, and you can, if you wish, 'push' the aspects into the Java classes to remove all traces of Roo from a project.

I think it's worth thinking of Roo as three things:

  1. an approach to automating the mundane elements of development
  2. an implementation of this approach in the form of a shell with command completion, hints, help, and a log/script replay capability, and a framework for parsing annotated Java classes and generating/maintaining related files
  3. the current set of commands and annotations that support rapid development of Spring Web applications.

There is nothing in 1 and 2 that ties Roo to Spring - the approach and tooling could be used for JEE6, and it would be interesting to consider what NakedObjects would look like if Roo was used to support it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.