Spring Roo: The Answer To Real Rapid Application Development?
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.