The recent release of Spring Roo, a round-tripping code generation tool used to develop Spring applications in Java, offers Tomcat, JMS and Selenium support. SpringSource development team released Roo 1.0 M1 version last week.
Spring Roo framework provides a command line shell with tab completion, context aware operations and command hinting features. It constructs the Java application in a standard directory format, manages the build configuration files, helps the developers create domain objects, integrates with popular persistence choices and provides automatic web tier generation for easy REST-based web user interfaces. It also offers dynamic finder methods and auto-generates the JUnit integration tests.
Roo project lead Ben Alex recently posted a blog entry about the new release of Roo with a sample application on how to install the framework and create Spring applications using Roo. SpringSource founder Rod Johnson wrote about the motivation behind Roo framework. InfoQ spoke with Ben Alex about the new framework and how it helps with the development of Java applications.
How does ROO address the real-world Java application requirement of auto-generate the boiler plate code and at the same time, provide the flexibility to add custom business logic and validation rules?
For all parts of Roo you can write code in your choice of text editor, IDE or other tool. Roo sits in the background and watches your project files. It then builds a comprehensive metadata model of your project. The metadata model allows Roo to identify what you've provided and what you'd like Roo to provide. It will then automatically provide those components. If you elect to later on provide some part of some of those components yourself, Roo again detects this and transparently removes its automatically-provided portions.
ROO framework uses Aspects to specify annotations like @Configurable. What was the rationale behind using AOP in Roo framework?
In terms of why do we use aspects as the underpinning of Java code generation, there are lots of motivations behind this and I'll cover them in the third installment of my blog series. But essentially I prototyped a few different alternative techniques that were available, including JSR 269, build-time source code generation, IDE plugins, bytecode generation at development time, bytecode generation at runtime and advanced reflective approaches such as extensions to Spring Framework AOP, DSLs etc.
My biggest priorities were to ensure:Secondary considerations were:
- The user's project must continue to work even if they stop using the tool; this immediately rules out anything that happens at runtime.
- The user's project must not compromise performance at runtime; this immediately rules out most reflective approaches.
- The developer must be able to use their existing Java knowledge, skills and experience. Thus the tool must support a normal Java programming experience, support programming in the developer's normal style, allow them to use their normal IDE, and access familiar tooling like the debugger and code assist. The tool must work with what the developer already knows, understands and expects. This eliminated any special bytecode approaches and also most runtime approaches.
- The tool must work automatically and not require specific invocation, build system integration or a specific IDE. It absolutely must support transparent and immediate round-tripping. This ruled out JSR 269 and build system-based approaches like we see with tools like XDoclet.
- The user's project must work on Java 5 and above. That rules out JSR 269, although there were lots of other reasons to avoid it (like fragile IDE support as of the time of prototyping).
- The tool should be easily extensible by end users. This was certainly easier when we approached it using the AspectJ techniques we used. It also discouraged using any IDE-specific techniques, which tend to require more complex development and deployment than do Roo add-ons.
- The tool should support long-term improvements to add-ons. This was made far easier using the separation of concern offered by AspectJ ITDs.
- The tool should be extremely lightweight: fast to download, fast to learn and fast to operate. This favored a shell-based approach with minimal dependencies. Roo 1.0.0.M1 is under 3 Mb to download!
Basically AspectJ ITDs plus an automatically-maintained metadata model represented the only solution we could find that would satisfy all of the requirements. If you're willing to sacrifice some of the expressed requirements, there are naturally other ways of addressing the problem.
How does Roo compare with other code generation tools like openArchitectureWare (oAW) and Skyway Builder from Skyway software?
oAW provides a model-driven approach to application development. I am sure there are many scenarios where MDA is very effective. Still, Roo is not an MDA tool. As I mentioned earlier when discussing the priorities behind Roo (and expressed in the ROO-1 issue), our critical priority is to deliver a non-invasive and productive tool that reuses existing Java developers' knowledge, skills and experience. We believe that most Java developers prefer to work with Java code and we therefore developed Roo to respect that and deliver them productivity via a code-first paradigm. This is quite different from a model-first paradigm.
As an aside, code-first is why IDEs are so popular in my view. People can code the way they like and still be more productive than not using an IDE. Developers can gradually use more features of the IDE as their comfort level increases. Developers can quit the IDE and their project still works. No "big bang" is needed to start using an IDE nor stop using one. An IDE doesn't need any runtime components (with the associated performance, compatibility, portability and approval questions). These are all ideal attributes and end user benefits for programming tools. Roo brings these to rapid application development.
Skyway Builder users generally create a diagrammatic representation of the desired application functionality. This is then internally mapped into Java source code. I am aware that Skyway are working on adding some scripting support to their tool based on the Roo syntax.
Both Skyway and oAW emit standard Java source code and are implemented as Eclipse plugins. Roo on the other hand emits AspectJ ITDs. We did evaluate source code emission techniques but felt it preferable to place the generated Java members into separate ITDs. This reduces the clutter in a class, ensures separation of concerns and offers compatibility with future versions of the relevant Roo add-ons. I'd also note Roo ships as a < 3 Mb ZIP file and therefore has a lighter footprint than Eclipse-based tools. Plus Roo can be used with a text editor or non-Eclipse IDE without any trouble. Roo can also be used with virtually no training - the developer can always write source code anywhere they wish and Roo will respect that. Using other tools requires the developer to understand the tooling requirements when they start to write code.
What are the recommended best practices and "gotchas" for Java developers who are interested in using ROO framework as part of their software development process?
Roo is still in an early stage of development, so while the technology is probably of interest to many Java developers who like Spring, we should bear in mind it has only been in public circulation for about a month now. We need a little longer to finalize the capabilities, fix bugs, receive feedback, write documentation, release 1.0.0.GA etc. We are very enthusiastic about receiving as much feedback as we can get, as this helps us deliver a high-quality 1.0.0.GA release (which will be around August 2009).
Regarding "gotchas", there is a list of known issues in the readme.txt. I don't think they'll affect most people, though, and we'll sort them out over time. There's also the public JIRA instance now lists other issues.
What is the future road map of ROO project in terms of new features?
As mentioned earlier, we're still focusing on 1.0.0.GA. Once 1.0.0.GA is out we will be splitting the shell portion out of Roo and into a standalone project that will be called Spring Shell. The Spring Shell can then be used by other projects needing a shell capability. Separately we plan on progressing some of the Generation IV webapp requirements (technologies such as Flex and GWT). We'll also be reflecting on which add-ons require further capability depth, and which new add-ons the community would like to see developed. The community can help by sharing their feature ideas, suggestions and experiences via the Roo community forum or issue tracker. We also keep an eye on the #roo Twitter channel for those people who enjoy a more informal and immediate way of offering feedback.
