With Roo it is possible for Java developers to build sophisticated enterprise applications in a best-practice manner within minutes. This is not just a marketing claim, but it's a practical fact you can experience yourself by trying the ten minute test.

Anyone who has programmed Java for a few years and looked at the alternatives on other platforms will be fully aware that enterprise Java suffers from productivity problems. It takes days to start a new project and incredibly long cycle times as you go about normal development. Still, we remain with Java because it's a highly attractive platform. It's the most widely used programming language on the planet, with millions of competent developers. It has first-class tooling, excellent runtime performance, numerous mature libraries and widely-supported standards. Java is also open source, has multiple vendors and countless choice.

We built Roo because we want enterprise Java developers to enjoy the same productivity levels that developers on other platforms take for granted. Thanks to Roo, Java developers can now enjoy this higher productivity plus a highly efficient, popular, scalable, open, reliable platform. Best of all, in five years time it will still be possible to hire millions of people who can look at those Roo-based projects and understand what is going on and maintain them (even if you've stopped using Roo by then).

Roo's higher productivity is provided both at original project creation, and also as a developer builds out the rest of the project. Because Roo provides round-trip support, the higher productivity is automatically provided over the full lifespan of a project. This is particularly important given the long-term maintenance costs of a project far outweigh the initial development costs. While you can use Roo just for an initial jump-start if you so wish, your return on investment is exponential as you continue using it throughout a project lifespan.

Finally, while individual productivity is important, most of us work in teams and know that someday someone else will probably maintain the code we've written. As professionals we follow architectural standards and conventions to try and ensure that our present and future colleagues will be able to understand what we did, why, and have an easy time maintaining it. Our organisations often establish standards for us to follow in an effort to ensure other projects are tackled in similar ways, thus allowing people to transfer between projects and still be productive. Of course, most organisations also have people of greatly differing backgrounds and experiences, with new graduates typically working alongside more experienced developers and architect-level experts. Roo helps significantly in this type of real-world environment because it automatically implements specific design patterns in an optimal convention-over-configuration manner. This ensures consistency of implementation within a given Roo-based project, as well as across all other Roo-based projects within an organisation (and even outside your organisation, which greatly helps with hiring). Of course, the fact Roo builds on stock-standard Java also means people of vastly different experience levels can all be highly productive and successful with Roo.

It's no longer necessary to switch platform or language to achieve extremely high levels of productivity! We designed Roo from the outset so those people with existing Java 5 knowledge, skills and experience would feel right at home. If you've ever built an enterprise application with Java, some or all of the technologies that Roo uses by default will already be familiar to you.

Some of the common technologies Roo projects use include Spring (such as Spring Framework, Spring Security and Spring Web Flow), Maven, Java Server Pages (JSP), Java Persistence API (JPA, such as Hibernate), Tiles and AspectJ. We've chosen technologies which are extremely commonly used in enterprise Java projects, ensuring you've probably either already used them or at least will have no difficulty finding hundreds of thousands of other people who have (and the resultant books, blogs, samples etc that exist for each). Also, because most of these technologies are implemented using add-ons, if you'd like Roo to use a different technology on your project it's quite easy to do so.

By using standard Java technologies, Roo avoids reinventing the wheel or providing a limited-value abstraction over them. The technologies are available to you in their normal form, and you can use them in the same way as you always have. What Roo brings to the table is automatic setup of those technologies into a Spring-certified best-practice application architecture and, if you wish, automatic maintenance of all files required by those technologies (such as XML, JSP, Java etc). You'll see this in action when you complete the ten minute test.

You'll also find that Roo adopts a very conservative, incremental approach to adding technologies to your project. This means when you first start a new project Roo will only assume you want to build a simple JAR. As such it will have next to no dependencies. Only when you ask to add a persistence provider will JPA be installed, and only when you add a field using JavaBean Validation annotations will that library be installed. The same holds true for Spring Security, Spring Web Flow and the other technologies Roo supports. With Roo you really do start small and incrementally add technologies if and when you want to, which is consistent with Roo's philosophy of there being no engineering trade-offs.

There are many examples of promising technologies that are simply too hard for most people to learn and use. With Roo we were inspired by the late Jef Raskin's book, "The Humane Interface". In the book Raskin argued we have a duty to make things so easy to use that people naturally "habituate" to the interface, that text-based interfaces are often more appropriate than GUIs, and that your "locus of attention" is all that matters to you and a machine should never disrupt your locus of attention and randomly impose its idiosyncratic demands upon you.

With Roo we took these ideas to heart and designed a highly usable interface that lets you follow your locus of attention. This means you can do things in whatever order you feel is appropriate and never be subservient to the Roo tool. You want to delete a file? Just do it. You want to edit a file? Just do it. You want to change the version of Spring you're using? Just do it. You want to remove Roo? Just do it. You want to hand-write some code Roo was helping you with? Just do it. You want to use Emacs and Vim at the same time? No problem. You forgot to load Roo when you were editing some files? That's no problem either (in fact you can elect to never load Roo again and your project will remain just fine).

Because Roo uses a text-based interface, there is the normal design trade-off between learnability, expressability and conciseness. No text-based interface can concurrently satisfy all three dimensions. With Roo we decided to focus on learnability and expressability. We decided conciseness was less important given the Roo shell would provide an intuitive, tab-based completion system. We also added other features to deliver conciseness, such as contextual awareness (which means Roo determines the target of your command based on the command completed before it) and command abbreviation (which means you need only type in enough of the command so Roo recognises what you're trying to do).

The learnability of Roo is concurrently addressed on three fronts. First, we favor using standard Java technologies that you probably already know. Second, we are careful to keep Roo out of your way. The more Roo simply works in the background automatically without needing your involvement, the less you need to learn about it in the first place. This is consistent with Raskin's recommendation to never interrupt your locus of attention. Third, we offer a lot of learnability features in Roo itself. These include the "hint" command, which suggests what you may wish to do next based on your present project's state. It's quite easy to build an entire Roo project simply by typing "hint", pressing enter, and following the instructions Roo presents (we do this all the time during conference talks; it's always easier than remembering commands!). There's also the intelligent tab completion, which has natural, friendly conventions like completing all mandatory arguments step-by-step (without distracting you with unnecessary optional arguments). There's also the online "help" command, sample scripts, this documentation and plenty of other resources.

Roo also follows a number of well-defined conventions so that you always know what it's doing. Plus it operates in a "fail safe" manner, like automatically undoing any changes it makes to the file system should something go wrong. You'll quickly discover that Roo is a friendly, reliable companion on your development journey. It doesn't require special handling and it's always there for you when you need it.

In summary, we've spent a lot of time thinking about usability and learnability to help ensure you enjoy your Roo experience.

Roo doesn't impose any engineering trade-offs on your project. In fact, compared with most Spring-based enterprise applications, we're almost certain you'll find a Roo application will have a smaller deployment artefact, operate more quickly in terms of CPU time, and consume less memory. You'll also find you don't miss out on any of the usual IDE services like code assist, debugging and profiling. We'll explore how Roo achieves this below, but this information is relatively advanced and is provided mainly for architects who are interested in Roo's approach. As this knowledge is not required to simply use Roo, feel free to jump ahead to the next section if you wish.

Smaller deployment artefacts are achieved due to Roo's incremental dependency addition approach. You start out with a small JAR and then we add dependencies only if you actually need them. As of Roo 1.0.0, a typical Roo-based web application WAR is around 13 Mb. This includes major components like Spring, Spring JavaScript (with embedded Dojo) and Hibernate, plus a number of smaller components like URL rewriting. As such Roo doesn't waste disk space or give you 30+ Mb WARs, which results in faster uploads and container startup times.

Speaking of startup times, Roo uses AspectJ's excellent compile-time weaving approach. This gives us a lot more power and flexibility than we'd ordinarily have, allowing us to tackle advanced requirements like advising domain objects and dependency injecting them with singletons. It also means the dynamic proxies typically created when loading Spring are no longer required. Roo applications therefore startup more quickly, as there's no dynamic proxy creation overhead. Plus Roo applications operate more quickly, as there's no dynamic proxy objects adding CPU time to the control flow.

Because Roo's AspectJ usage means there are no proxy objects, you also save the memory expense of having to hold them. Furthermore, Roo has no runtime component, so you won't lose any memory or CPU time there either. Plus because Roo applications use Java as their programming language, there won't be any classes being created at runtime. This means a normal Roo application won't suffer exhaustion of permanent generation memory space.

While some people would argue these deployment size, CPU and memory considerations are minor, the fact is they add up when you have a large application that needs to scale. With Roo your applications will use your system resources to their full potential. Plus as we move more and more enterprise applications into virtualized and cloud-hosted environments, the requirement for performant operation on shared hardware will become even more relevant.

You'll also find that Roo provides a well thought out application architecture that delivers pragmatism, flexibility and ease of maintainability. You'll see we've made architectural decisions like eliminating the DAO layer, using annotation-based dependency injection, and automatically providing dependency injection on entities. These decisions dramatically reduce the amount of Java and XML code you have to write and maintain, plus improve your development cycle times and refactoring experiences.

With Roo, you don't have to make a trade-off between productivity or performance. Now it's easy to have both at the same time.

One of the biggest risks when adopting a new tool like Roo is the ease at which you can change your mind in the future. You might decide to remove a tool from your development ecosystem for many different reasons, such as changing requirements, a more compelling alternative emerging, the tool having an unacceptable number of bugs, or the tool not adequately supporting the versions of other software you'd like to use. These risks exist in the real world and it's important to mitigate the consequences if a particular tool doesn't work out in the long-term.

Because Roo does not exist at runtime, your risk exposure from using Roo is already considerably diminished. You can decide to stop using Roo and implement that decision without even needing to change any production deployment of the application.

If you do decide to stop using Roo, this can be achieved in just a few minutes. There is no need to write any code or otherwise make significant changes. We've covered the short removal process in a dedicated removing Roo chapter, but in summary you need to perform a "push in refactor" command within Eclipse and then do a quick regular expression-based find and replace. That's all that is needed to 100% remove Roo from your project. We often remove Roo from a project during conference demonstrations just to prove to people how incredibly easy it is. It really only takes two to three minutes to complete.

We believe that productivity tools should earn their keep by providing you such a valuable service that you want to continue using them. We've ensured Roo will never lock you in because (a) it's simply the right and credible thing to do engineering-wise and (b) we want Roo to be such an ongoing help on your projects that you actually choose to keep it. If you're considering alternative productivity tools, consider whether they also respect your right to decide to leave and easily implement that decision, or if they know you're locked in and can't do much about it.