Rapid Prototyping with Spring Roo

Spring Roo, a new contender to Grails and Ruby on Rails, provides flexible scaffolding for Spring based applications. We used Spring Roo in a web project to quickly provide working software in order to discuss features and gather feedback. This article shows how we generated an early prototype and transitioned to early development and then to production code.

Spring Roo‘s mission is to “fundamentally and sustainably improve Java developer productivity without compromising engineering integrity or flexibility“. It follows the Convention over Configuration principle, and provides rapid application development for Java EE applications.

Spring Roo itself isn’t a framework; it’s more like a software tool for generating Java EE web applications with CRUD functionality. This means the user can create, read/find/list, update and delete entities. Spring Roo offers several technology options, like various providers for the JPA-based persistence (e.g. Hibernate and EclipseLink), Spring MVC controllers and a frontend based on either JSPs, JSF 2.0 (coming in Spring Roo 1.2), Google Web Toolkit (GWT) or Flex. If you want to change your persistence provider, you could easily do this; if you want to add a JSON output (or whatever else is needed) to the controllers, you could add it with only small effort. And everything integrated into the project has a reasonable “default” configuration, so that very little configuration overhead is needed.

The toolset of Spring Roo can generate code and integrate a lot of standard modules into a Java EE project, with very little configuration overhead, leaving you always the choice to modify everything you need. So with some easy commands you can add technologies like JMS for messaging, JSON for REST, Solr for full-text search etc.

How does Spring Roo work?

The heart of Spring Roo is the Roo Shell with a really great help system, which is self-explaining and easy to use. From here you could setup your JPA provider, create entity objects etc.

There are lots of examples where you can quickly try out Spring Roo. In those, Spring Roo creates a complete project for you, including a Jetty server and a in memory database if needed.

We will use our own short example to explain a few features along with the article.

A Short Example

We are going to build a simple address database, where a person can have multiple addresses. Setting this up is a really easy process:

  1. First install Roo from the Spring Roo homepage and add the bin folder to you path.
  2. Then create an empty folder and start Roo with roo.sh (or roo.bat) from within this folder.
  3. Next, follow the following commands to setup the project. You can type “hint” anytime, showing a smart help system which suggests you the next steps.

project --topLevelPackage de.mgm.roo.sample

After this command an initial project will be created.

Here we will choose Hibernate for persistence and the Hypersonic in-Memory Database as specific database:

persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY

A Spring Roo project is usually created and modified in the Roo Shell.

There are lots of ORM technology options and databases to choose from, nearly all you would find in a normal environment.

Project structure generated by Roo.

This is our first entity, the Address:

entity --class ~.domain.Address --testAutomatically
field string --fieldName street --notNull --sizeMin 2
field string --fieldName city --notNull --sizeMin 2
field number --type int --fieldName postcode --notNull

This is our second entity, the Person, which can have several addresses:

entity --class ~.domain.Person --testAutomatically
field string --fieldName lastname --notNull --sizeMin 2
field set --fieldName addresses --type ~.domain.Address

Pressing Tab during the commands shows you all available options.

The new entity classes are reflected in the Eclipse IDE.

After the following commands, we have a fully working web application, that can be imported into eclipse (other IDEs are available as well):

perform eclipse
controller all --package ~.web

The Web tier and resources are created through the Roo Shell.

This application can be started easily with the command “mvn jetty:run” and you have the following web application:

The out-of-box generated Web application.

The core modules are included and managed via the OSGI implementation Felix, so the Roo-Shell also supports all OSGi Commands, e.g. to load and unload modules. You should take a look at the module list.

But how does Spring Roo manage the generation and even modifications?
Try to add a field to your entity object and Spring Roo will update everything for you.

How does Spring Roo work technically? Spring Roo uses AspectJ mixins called inter-type declarations in order to achieve separation of concerns, because the Spring Roo code is in a different compilation unit, as the code the user writes. So Spring Roo can modify it files as it needs them, without getting in conflict with the user.

Spring Roo as a Rapid Prototype tool

As the headline suggests, we used Spring Roo with a customer for Rapid Prototyping. Because the specific project had a very short timeline, there was not much time for a long requirement phase, so we tried rapid prototyping instead. So the customer got a very early working base, from where we could add and remove requirements on interacting cycles. Another problem were the changing requirements.

The general concept of the application was very clear, but the details like fields and entities changed. This is where rapid prototyping did really help. Rapid prototyping allowed us to show a lot of changes to the customers early in our development cycle so that we began getting the feedback that will be crucial to the success of the project. Not only the showing was successful, also the “usage” by the customer did help.

The requirement phase was followed by an early development stage:

  • At first we developed the data model/entity model with the customer and transferred it to Spring Roo, then added
  • the web frontend generated and maintained by Spring Roo, and
  • the layout and CSS styles for the customer to see.
  • We then included the existing databases with DBRE (Spring Roo Database Reverse Engineering),
  • showed the system to the customer and added/removed entities and attributes as needed, and
  • finally added security.

Adding and Removing Attributes and Entities

There are different ways to add and remove entities in the existing project. The first would be using the Roo shell to add and remove fields of an object. This is the most obvious way. But another, much better way is changing the classes directly, i.e. in the Java code.

Lets take a look at a domain object, generated by Spring Roo. The Address entity looks pretty clean and straight forward. The getters and setters are managed by Roo, but you can easily overwrite and modify them as you wish.

So lets add an field to our address. We noticed that the country is missing, so lets add this! I just added the following code:

@Size(min = 2)
private String country;

As soon as I save the domain object, Roo updates the project and the new field appears in the web application. Here’s an excerpt from the Roo shell output:

Updated SRC_MAIN_WEBAPP/WEB-INF/views/addresses/list.jspx
Updated SRC_MAIN_WEBAPP/WEB-INF/views/addresses/show.jspx
Updated SRC_MAIN_WEBAPP/WEB-INF/views/addresses/create.jspx
Updated SRC_MAIN_WEBAPP/WEB-INF/views/addresses/update.jspx
Updated SRC_MAIN_WEBAPP/WEB-INF/i18n/application.properties
Updated SRC_MAIN_JAVA/de/mgm/roo/sample/domain/Address_Roo_ToString.aj
Updated SRC_TEST_JAVA/de/mgm/roo/sample/domain/AddressDataOnDemand_Roo_DataOnDemand.aj
Updated SRC_MAIN_JAVA/de/mgm/roo/sample/domain/Address_Roo_JavaBean.aj
Updated SRC_MAIN_JAVA/de/mgm/roo/sample/web/ApplicationConversionServiceFactoryBean_Roo_ConversionService.aj

You can keep Roo running when you modifying a class outside of Roo – it should detect changes, or it will do it on next restart.

Added fields are reflected in the Web application (here “country”).

You can use the same way to create and delete entities – just create or delete the classes as you need. Tip: A good practice is changing the entities and attributes, but all other stuff should be changed through the Roo shell, like adding and removing security etc.

Removing Spring Roo from Project

After this early development phase, we decided to remove Spring Roo, resulting in a regular Spring based web application, and continued with “normal” Java Development. This way is intended by the Spring Roo authors; there is a whole chapter of removing Spring Roo from a project.

From this point on, we refactored the entity layer (just to get more structure in the packaging etc) and got a quite nice Java EE App as a working base.

Spring vs. Grails vs. Ruby on Rails

Here I want to explain shortly why we chose Roo over Grails and Ruby on Rails. The quickest answer would be, because there was a requirement to develop in Java. But I want the show a little bit about the advantages and disadvantages of this three comparable systems.

Ruby on Rails is a very powerful platform with a large community, but you would have to learn Ruby and you would have to understand Rails as a platform. You couldn’t use existing modules (in Java) easily.

Grails has also a very good community, uses standard Java technologies like Hibernate and runs on the JVM. Here, the only effort would be learning the Groovy language. But on the downside, Groovy is always a little bit slower than native Java. Here the main aspect against Groovy was again the language.

Spring Roo has a very small community, but help is available. The advantages here were that Spring Roo creates “regular” Spring Projects as soon as you remove Spring Roo itself.

Another interesting option is AppFuse, which focusses more on the initial scaffold of a new project (a bit like Maven’s archetypes). We had no chance to investigate it, but consider the Discussion “Appfuse vs Roo – what would you use”.


Spring Roo is definitively useable as a tool for Rapid Prototyping, i.e. to quickly and easily create a first usable application. But you should face the fact that the current version 1.1.2 still has a lot of missing features (like composite primary keys) and bugs, where you suddenly need a solid understanding of AspectJ and databases. This was the main reason why we decided, after the requirements phase, not to continue working with Spring Roo.

The real great upside was, that we got a complete application up in running in a few days with a clean codebase where we could easy start from developing all the details needed in the application. The CRUD web pages created by Spring Roo and the RESTful architecture are a great help extending the application clean and fast.