Java has been the world’s most popular programming language for well over a decade. You can find it running everywhere: on super computers, servers, set top boxes, PCs, phones, tablets, routers, and robots. There are millions of expert engineers fluent in it, libraries for every conceivable purpose, and unparalleled tooling and management capabilities.
Despite Java’s success, few people consider it highly productive for quickly developing enterprise applications. Indeed, if we step back to the year 2000, the mainstream model revolved around a standard called EJB 2. It promoted patterns that are unthinkable in the modern era, including vast deployment descriptors, code that was virtually impossible to unit test, confusing lifecycle methods, meaningless layers, excessive redeployment delays, and so on.
These problems would not remain unchallenged. In the early 2000s, Spring introduced a vastly more productive approach that quickly replaced EJB 2 for new applications. It also significantly popularized the use of open source within traditionally conservative organizations that had previously only allowed vendor-endorsed products. Today, most developers enjoy considerable latitude in their ability to use liberally licensed open source software.
Convention-over-configuration web frameworks started to gain traction by mid-decade. Ruby on Rails in particular exploited a range of dynamic language capabilities to further raise the bar of enterprise application development productivity. Grails delivered similar benefits on the JVM by combining Spring’s solid enterprise foundations with Groovy’s dynamic language capabilities.
Implementing a convention-over-configuration web framework for Java was challenging because of its static typing model, so I designed an incremental active code generator that would emit mixins. This allowed multiple compilation units to be woven into a single class file. Mixins ensured that generated code would be conveniently managed without developer interaction and without losing important Java features such as code assist, debugging, source visibility, profiling, performance, and so on. The approach had not been attempted before, but it worked out nicely, and today other code generators also emit mixins (for example, Apache Magma).
One unique benefit of Spring Roo’s convention-over-configuration model is the absence of any runtime component. It operates only at development time, just like Maven or Eclipse. This makes Roo completely free of lock-in or runtime expense, such as memory or CPU time. Many people use Roo to start a project and then stop using it, while others keep using it indefinitely for the same project. Since 2008, there have been tens of thousands of projects built using Spring Roo. It brings you the proven productivity benefits of convention over configuration, but with the substantial advantages of Java.
Spring Roo in Action is an insightful and comprehensive treatment of Spring Roo. Ken Rimple and Srini Penchikala have worked closely with the Roo community and engineering team for over two years, with countless emails, tickets, and forum posts that dig deep into the Roo internals. They have carefully tracked Roo’s development and inspired multiple improvements. The result is a detailed book that is extensively researched, up-to-date, authoritative, and pragmatic. I hope that you enjoy Spring Roo in Action and the significant productivity enhancements it will bring to your application development journey.
Spring Roo, Spring Security
and Spring UAA