Chariot Solutions TechCast #45 – An interview with SpringSource’s Ben Alex on the SpringSource Roo project.
Disclosure: SpringSource is a Chariot partner
Transcription provided by Jo Middleditch (mconsult at msn.com)
[Ken Rimple] – Welcome to the show. I’m Ken Rimple. This week we feature SpringSource’s Ben Alex. One of the founders of SpringSource, Ben created the widely adopted Spring security framework originally known as ACEGI. Ben’s current project is framework named Roo. Ben being from Australia, think of Roo as in “kanga”. Roo doesn’t use dynamic meta-programming to accelerate development. Instead it focuses on building applications in native Java using APIs like JPA and Spring MVC.
I caught up with Ben this week via Skype shortly after the American SpringOne 2GX Conference. Here’s the interview.
[Ken Rimple] – All right. Well, Ben Alex, thank you so much for being on the Chariot TechCast.
[Ben Alex] – Thank you very much Ken.
[Ken Rimple] – So why don’t we start a little bit by talking about your background. Now, if I remember correctly you were the creator of Spring Security. And if I also remember correctly I think that started as an open-source project separate from Spring itself?
[Ben Alex] – That’s fundamentally correct. Back in 2003, I started the ACEGI project, which later went on to become Spring Security. So for about seven years I’ve been working with Spring now. I was [one of the] founders of SpringSource. I was involved in the first commercial projects of SpringSource back in 2004 and I also set up the Australian operations of SpringSource. So I’ve trained about 500 people in Spring and these days I’m an engineer in SpringSource.
[Ken Rimple] – So now your current project that you’re really working on hard here with your team is SpringSource Roo. Now I know we have convention over configuration frameworks that are getting very popular these days, like we started with Ruby on Rails and then, for example, in the Groovy community we’ve got Grails. Spring Roo’s kind of like that but it’s a bit different. Why don’t you kind of explain what the problem is that it’s trying to solve and what it’s all about?
[Ben Alex] – I mean, Roo’s mission is to fundamentally and sustainably improve Java developer productivity without comprising engineering integrity or [INAUDIBLE]. What that means is it’s really focused on a few key points. First of all, it’s about higher productivity. Java is the most widely used programming language in the world and at SpringSource we’ve obviously been big fans of Java for a long time and we thought, how can we bring much higher productivity to Java programmers. We also thought about using stock standard Java. So that means don’t provide extra obstructions just use the stuff that people usually want to use in Java based enterprise projects. So we used things like Spring and Maven and JPA and JUnit and JSP, tiles, AspectJ. All the typical sorts of things that you see in most Java enterprise projects. And by using these standard Java tools we’re able to redevelop existing [INAUDIBLE] an experience to make sure that it was very useful and loadable. So we had a look at other productivity tools out there and we thought that one thing we should really try to do with Roo is make it so that you don’t really have to read the manual. So we had some work done by Jim Raskin who wrote a great book called The Humane Interface. And it’s a really good read if listeners are interested in learning about usability and thinking about things the way a user would think about things. But the natural fallout from that was a really, really good shell and some very natural usability experiences. We also thought a lot about the engineering tradeoffs. We thought what would stop people from using Roo? And we thought, “Well if you need to get approval to run this thing in production you’re going to need special approval and that’s not going to be very good if it’s going to consume memory or it’s going to slow down your system, or it’s going to make your deployment artifactaully big, that’s no good.” So we did an engineering approach–which essentially means that Spring Roo applications will generally run faster than a handwritten Spring application, the old-fashioned way. And the main reason for that is that we basically have done optimizations in the code that we generate and it’s using AspectJ instead of using some dynamic proxy based approaches. The final thing that makes Roo a bit different from everything else is it has easy removal. So you can get rid of Roo in two or three minutes. There’s absolutely no run time portion of Roo so it’s more like Eclipse or one of your development tools than it is a framework like Spring.
[Ken Rimple] – Right. Now so for somebody who hasn’t done anything with Roo before you download Roo, you set up in your path and basically in a couple of command line entries you can create a Spring application.
[Ben Alex] – That’s right. Yes. I mean, with Roo you’ve got this interactive shell. So what you do is you just start with the shell and it just sits there and it has a little Roo prompt and you type “hint” and press “enter”. And once you’ve typed it, it tells you what to do. So first thing you usually do is the project command and that will create you a new project. You can quit Roo at this point and if you exit Roo you’ve got a fully set up Spring project ready to use for something like Maven. But most people will probably want to install some data so the next command you type in is “persistance set up”. There’s tab completion all the way so you don’t have to remember the commands; you just have to type a few letters and press the tab key. And persistence set up lets you set up your choice of JPA provider and database. Again you can exit at this point and get off and work with the project in Eclipse or STS or Emacs or vi if that’s your thing. But mostly […] they go on to create some entities and create some fields. You can do that through the Roo command interface. If you use this command interface it’ll do interesting things for you like automatically create tests, so you’ve got integration tests for free. It will do things like help you avoid things like gotchas like accidently using SQL key words for your names. And once you’ve done that you can then [issue the] “controller all” [command]. What “controller all” does is it goes and builds you a web stack, so it installs…makes you a project a web project because up until this point it would have just been a standard [command line] project. Installs Spring MVC, installs tiles, installs the necessary JSP tag libraries and you can exit at this point and you’ve got a web application ready to run something like Maven. So that the upshot of all that is that you’ve done it in about ten minutes. You’ve started an application. You’ve built your domain model, you’ve put some entities into it. You’ve got a web stack, tests. You’ve got things like selenium tests so you can go off and check the web stack works okay. You’ve got your JUnit tests. And you can try all of this from the command line. You can use things like Maven, mvn test and mvn package and all of those commands just work straight out of the box.
[Ken Rimple] – Now, again, behind the scenes what’s happening there is it looks like – and just from using it a little bit – it looks like what you’re doing is you’re annotating the classes and behind the scenes you’re generating some aspects and wiring them together. Can you talk a little bit about the engineering behind that?
[Ben Alex] – What’s happening behind the scenes is the Roo shell is running in the background. So you can either let it run in the background or you can be interacting with it in the foreground. But either way, Roo will monitor the file system to see what you’re doing outside Roo. So if you’re making changes in Eclipse, it will pick up the fact that the files have changed and then it will respond accordingly. What it does is it builds a metadata model of your project so it understands all of the key types in your project. All of the members of those types and so on and then it applies its automatic logic to it. This automatic logic generally will result in it changing files on your file system or creating files or deleting files. It’s very conservative. That sounds quite frightening when you first hear it but it’s extremely conservative. It never touches a file unless you actually ask it to through one of the app Roo annotations. What types of files it generally will output are what we call AspectJ intertype declarations.
An intertype declaration has other names [outside of] AOP. You might have heard them called mix-ins or introductions but they basically work the same way. A mix-in or an introduction puts members in a different compilation unit from your target class. So you’ll have your “Person.java” file. Roo [will] automatically create for you a “Person_Roo_toString.aj” file. And in that “Person_Roo_toString.aj”, we’ll [write] the toString() method. So the compiler…by the time the compiler runs, the members from these ‘.aj’ files are merged into the members from your ‘.java’ file and your ‘.class’ file has all of the members. So what it does is it gives us a really, really elegant way of doing active code generation.
When we do code generation, we’re outputting an AspectJ file instead of touching your “.java” file. And this is really critical because it lets us do clever things like automatically upgrade the contents of the AJ file as you change a project. It lets us do things like, when we bring out new versions of Roo and we improve the way that we generate the code – like we make a better two string, you get the better two string method for free without having had to do anything. You also find that your actual […] Java source files are very small. So if you take a look at a typical Roo project the ‘Person.java’ file just has in it the actual business logic and the fields that are to do with person. It doesn’t have all the tedious getters and setters and “toString()” [methods] and persistence related methods because Roo takes care of all those for you automatically.
What I often do when I show people Roo is [that] I show the fact that you can write your own toString() method or your own getters and setters in the ‘.java’ file and Roo will automatically step back and will delete the corresponding Roo generated files. So it’s a very natural process. You don’t have to think about the fact this is happening. In the background, Roo keeps an eye on what you’re doing. If you start to do something that Roo was doing for you, Roo will stop doing that for you and let your work take priority. You don’t have to explicitly tell Roo, “I want to do some coding here.” You just let Roo do it for you automatically.
We also use AspectJ in a few other ways. Things like the @Transactional advice. We’re using AspectJ to do that. We’re also using @Configurable if you’re familiar with that from Spring Framework. This lets us dependency inject entities so you’re able to have any object in your system, even objects that are created with the new keyword or reflectively or through a persistence provider, all of those can be dependency injected. And as a result you get these nice highly efficient objects. It lets you do more object-oriented programming because you can make sure that you can do any kind of dependency injection you want on any object on your system.
[Ken Rimple] – Now I also noticed that if you’re doing your typical Spring development usually have a service layer and the service layer has repositories, let’s say. And you normally have that kind of separation and it looks like what you’re doing is similar I guess to a lot of the other domain driven applications where you’re actually mixing in the repository methods on the entity itself.
[Ben Alex] – That’s right. So with Roo we tend to put the persistence-related methods on the entities themselves. So it’s a little bit like active record but I’d argue it’s different from active record in a few key ways. First of all, the methods that you find on the entities tend to be the same method names as the JPA specification provides. So they’re names like “persist” and “remove”. As a result the conceptual weight is lowered by using Roo because you already know what those methods do. It also participates in JPA in the standard official way. So all those methods do is they delegate straight through to the underlying JPA provider. It’s using the same…the correct and the same JPA transactional context as would have been used if you’d written a repository layer by hand. We put these methods onto the entities because it makes it simple from a compilation unit point of view. You don’t want to have to have extra layers that are basically doing nothing but delegating through to JPA anyway. You’ll also find that nearly all modern RAD frameworks tend to do this whether you’re talking about things in the Java space or the Groovy space or the Ruby space or the Python space. Everybody is doing it this way these days. The persistence methods simply go onto your entities, your domain objects or whatever the equivalent is in the programming language that you’re using.
[Ken Rimple] – Right. And I guess if you’re looking at the…I’m looking more like a Spring architect here so I’m taking a look at the controller generated code. So I guess through, what, the aspect-oriented nature of this, the transactions get weaved in? Like where do the transactions get demarked really?
[Ben Alex] – It varies a little bit. The transactions get demarked I believe on the web tier for…I mean, there’s two transactions in fact. There’s a… we use the “open entity manager in view” [filter] so you’re ending up with a read-only transaction so that the view can be rendered without having any kind of lazy initialization-related issues. And then the actual real transaction is happening when you start the execution of the controller’s handle method.
[Ken Rimple] – So you’re just basically simplifying it out of that service oriented…or service based layer?
[Ben Alex] – I mean, services layers still have a very valid role in Roo based applications. And people can build a services layer just by creating a class and annotating it with the @Service annotation. And they can do their transactions in there as well. I mean, you have all the normal power of Spring. You can use all the normal Spring techniques if you wish. About the only thing that’s a little bit different with the Roo app from what most people would be used to is the fact that we’ve put the persistence methods into the entities using inter-type declarations. Once again, people don’t see this. If they open up the entity they won’t see these methods [in the original] Java files but they’ll be there if you press control space in Eclipse or equivalent because they’ve been woven in automatically. In terms of where would you put your business logic, where would you coordinate multiple entities? You’d still do that in the services layer because it’s just the same as a normal Java program.
[Ken Rimple] – I guess a fair question that people have been asking is [that] right now, inter-type declarations are really easy to work with in Eclipse because you’ve got the AspectJ plug-in. Now what about other IDEs? You know, people from like an IntelliJ side or from a NetBeans side of the house. Where do you stand on using Roo with other IDEs in the long term?
[Ben Alex] – Just to give you a bit of history, midway through last year I prototyped about seven different ways of building this tool. We looked at different technical approaches that were available, and some of the prototyped approaches included doing things like generating byte-code at load time, generating source code using other techniques, using the Java 6 annotation processing API and a whole ton of other techniques. And one of the key reasons we used AspectJ was because it was incredibly mature and widely supported in existing IDEs. If we started a project like Roo and it required an Eclipse-specific plug in we would have written that. We have plenty of really good Eclipse guys at SpringSource and we could have done that really easily. But the trouble is we would have then had to go to NetBeans and we would have then had to go to IntelliJ and say, [there is this] new open source tool called Roo” and we would have had to convince them to go off and write a plug-in, or we would have had to rely on the community to write a plug-in. So by using AspectJ we were able to use the plug-ins that already existed on their IDEs. Now of course, plug-ins vary by quality and you’ll find that the Eclipse plug-in, […] ADJT, is [of] extremely high quality because we have the guys who are responsible for that plug in actually working for us, so we work with them very closely and make sure that that plug-in works brilliantly with Roo-based applications. For the other IDEs the [AspectJ] plug-in is less sophisticated because we don’t look after it, but it’s a relatively small gap for people using those other IDE’s to use Roo.
With Roo you don’t actually have to use an IDE. We have people using Roo with vi and with Emacs. It makes no difference at all how you edit your files. Roo doesn’t mind. It doesn’t need to be notified through any special internal callbacks or anything like that. So we’re hopeful that over time, things like IntelliJ and NetBeans will get better AspectJ integration. They’ve already got some AspectJ integration. It’s just a question of them enhancing their plug-ins ever so slightly so they fully support the current version of AspectJ.
[Ken Rimple] – Yeah. And the inter-type declarations. […] That’s the big issue?
[Ben Alex] – Most of them already support inter-type declarations. The problem is simply their code-assist, so their control space equivalent is usually not showing the members from an inter-type declaration. Indeed, up until we started doing this work with Roo last year even the AJDT plug in and Eclipse didn’t support that very reliably. So we made a lot of improvements to AJDT, which has benefitted the AspectJ community whether they use Roo or not; they’ve got a much better plug in as a result of the renewed interest in using things like Roo and using inter-type declarations. There’s another project also. Over on the Apache Foundation and they’re also using inter-type declarations with their code generating inter-type declarations. So they too are going to benefit from all the good work that’s going on with AJDT.
Given that this is obviously an approach that’s resonating with people through things like Roo and the Apache Project I think you’re going to see more and more pressure on the other IDE’s to make sure their AspectJ integration works well. As I said earlier, they’ve already got AspectJ integration. It’s just a case of finishing the AspectJ integration so it properly supports inter-type declarations just like AJDT does. It’s not like we’re asking them to go off and build a Roo specific plug in. They do this work and they get the whole AspectJ community involved in it and it’s a massive number of users. They get new tools like Roo and the Apache Project all working nicely in their IDE’s so they’ve got a lot to gain by investing a relatively small amount of effort.
[Ken Rimple] – Yeah. It’s almost like the architectures and the new techniques are kind of wagging the dog on the IDE support. Which is great. Now I guess going down the road of playing around with Roo and experimenting with Roo I found it to be a really good way of experimenting with Spring 3. For example just, you know, firing up an application, building it quickly and experimenting with JPA or with JMS or email or a variety of different API’s.
[Ben Alex] – There are people [who are] loving this for experimentation. I mean, with Roo if you’re wanting to get involved with Spring 3, which is due to go GA in the next couple of weeks, you’ll be able to download Roo and you’ll be able to see the latest and greatest ways of using Spring 3, because we track what Spring 3 are doing. I mean […] every few days we talk to the Spring 3 guys and as a result, we know exactly what they’re up to and we’re concurrently doing work in Roo to support what the next release of Spring is going to do. It’s very, very up-to-date.
It’s…I mean, for example, there’s a new annotation which you can use in Spring MVC controllers, the validation and binding API annotations, and we’re already doing support for that so stuff that hasn’t yet been released in Spring 3 we’re already supporting in Roo. And the next release of Roo will be a couple of days after the next release of Spring. So if you want to see the latest, genuinely the latest way of using the correct Spring MVC and the correct Spring annotations and the correct Spring XML and so on, if you use Roo it will give you the perfect architecturally endorsed best practice latest thinking in terms of how to actually use Spring correctly.
[A] nice thing about Roo which I didn’t sort of emphasize earlier is it’s so easy to remove. It takes two or three minutes. So you can build a Roo based application, right click it and then push in re-factor and essentially you can remove Roo from the application. So you have no ongoing dependency on Roo. So you could just build your application and then throw Roo away and Roo’s perfectly comfortable with that. So it’s like a really, really super duper sample delivery system.
[Ken Rimple] – Yeah. Exactly, exactly. It’s a really…if anyone hasn’t tried it yet, you definitely should – if you’re a Spring developer you should definitely download Roo and just give it a shot because it’s one of those things where you use it once or twice and it starts to click. “Ah. This is a great tool to have in my tool belt.” Now, plug-in support. It looks like you’re adding support for plug-ins. Is that in RC3 or is that in a coming release?
[Ben Alex] – So with Roo RC3, which came out about ten days ago, we added the first support for community developed add-ons. With community developed add-ons what these do is they let people build an add-on using Roo. You can build an add-on with Roo just using one line. You go “project — template roo-add-on” and it will automatically give you an add-on which you can then go off and customize and package ready for deployment. Because it’s so easy to build these add ons and people install these resulting add on zip files into their own Roo installation, we’ve got a lot of interest in this. In the last day I’ve received something like 80 emails from people saying, “Please send me your deep dive technical presentation so that I can learn how to write an add-on.” And we’re currently working on documentation to put this into the reference guide. Despite the fact we haven’t yet documented how to write an add-on, in any kind of official way, we’ve already in the last ten days seen four add-ons emerge. So there’s a lot of interest in writing add-ons and we thoroughly encourage people to write add-ons because Roo itself is going to remain relatively focused. We have these base add-ons that ship with Roo and those base add-ons just deal with things like Spring framework and Spring security and JPA and JMS, etc. We don’t try…we’re not trying to include the whole kitchen sink in the Roo distribution. The Roo distribution, by the way, is really small. It’s 2.8 megabytes.
[Ken Rimple] – Yeah. It’s very tiny.
[Ben Alex] – We want to keep it very, very small so that…Yeah, I mean it’s a real priority of ours to keep this thing lean and mean. And the way we’re going to keep it lean and mean is by having this unit of modularity called an add-on and let people write their own add-ons. It’s really good too because organisations that want to extend Roo or customize it to their particular needs, they could go off write an add-on and then they can install that into all of their development machines. And it doesn’t have to be published in any kind of central place. At the present time if you’d like to learn how to write an add-on you can send me an email and I’ll happily send you the Roo technical deep dive presentation which goes through, in great depth, how Roo works internally [including] all of its metadata models and APIs. We’re also working on documentation so by the time the next major release is out we should have these pretty well documented so people can write an add on. But take comfort from the fact that there has already been four add-ons released in the last ten days, so it’s not that hard to write an add-on. Roo itself is used to write add-ons. You just use “– template roo-add-on” and off you go.
[Ken Rimple] – Excellent. So now at this point, SpringSource kind of has two convention-over-configuration frameworks. You’ve got Grails and you’ve got Roo.
[Ben Alex] – I mean, SpringSource fundamentally is about productivity on the JVM and choice. I mean, Spring all along has given choice. […] If you go way back to 2003 when Spring first hit the streets, it did things that gave you a choice of data sources and data base abstractions. And it gave you a choice of persistence transactional APIs. And so it’s been [providing] choice from day one, and it’s still [providing] choice today. And that’s why we have both of them. We have Roo and we have Grails. The main difference between the two of them is in the language that you program them with. So clearly with Roo you program the whole thing in Java. With Grails you program it in Groovy. And it’s really just a case of you’ll choose the language which you prefer based on the typing discipline and the background that you have and what you prefer. There are also other differences in approach, so with Roo we’re development time only, so that means that it’s more like Eclipse. […] Whereas with Grails, it does all of its good stuff with dynamic languages so therefore it’s actually part of your runtime. It has this extra layer of abstraction on top of Spring and Hibernate and the other technologies that it provides utilities for. So they differ in approach, they differ in language. They also differ in things like page generation so with Groovy you use something like GSP. With Roo you use JSP. With Grails you use GORM. With Roo you use JPA, generally. By default with Grails you’ll use Gant. With Roo you’ll tend to use Maven by default. So there are actual implementation differences between the two of them as well. So it’s just a case of what people prefer based on their background knowledge and experience.
[Ken Rimple] – Great. Now, so what are your future plans for Roo at this point? You’re readying another milestone release or release candidate release. How many more of those do you think you’re going to have before you hit the true 1.0?
[Ben Alex] – There’ll only be one more release candidate, which will be RC4. RC4 is due at the end of November. We’re just waiting for Spring 3 to go GA. Once it goes GA, we’ll go to RC4. Then about a fortnight later we’ll release GA. So we’ve had something like eight releases of Roo throughout the 1.0 preparation phase. We’ve had alpha releases, milestone releases and release candidates. So we’ve had plenty of community feedback. In fact, we’ve been really thrilled with the level of community feedback and excitement we’ve had. I mean, there’s well over 400 issues have been logged into JIRA which is just amazing for a product that hasn’t even reached 1.0 yet. I compare that to where I went through Spring security in it’s ACEGI days, and this project has just really resonated with the community […] we just can’t believe the level of interest that it has. So, yeah, it’ll be GA by probably mid-December and we’ll probably follow it up with a 1.01 once Spring 3.01 hits the streets.
[Ken Rimple] – Yeah. You guys have been fantastic. I’ve logged some JIRAs myself early on and it was literally a day, two, three, four day turnarounds for a product that’s still being developed. I thought that was fantastic.
So now if people want to go and find out more information about Roo, there’s springsource.org/roo [which] is the main page, right? And the forums are great. Are there other that places that you would push people to to take a look at?
[Ben Alex] – I mean, certainly springsource.org/roo is the main landing page. There also are the forums. forum.springframework.org. There’s a dedicated Roo forum there which the Roo team monitors, and we tend to answer everyone’s queries. If you want really good fast free support that’s a good place to go.
[Ken Rimple] – I agree!
[Ben Alex] – There’s also Twitter. There’s a #roo [hashtag] if you’d like to…we keep an eye on the #roo key. So you can include that in your tweets. I mean again, we really love feedback, whether you like it, dislike it. Found it easy to use or found it hard to use, we really want to hear from people because it helps make our product better by knowing what people found good and what people found bad about it. We tend to have, as you probably told from the podcast and some of my answers, we tend to have pretty strong opinions on things like usability and architecture. Nonetheless, we absolutely welcome feedback and if you do ask us questions about these things, you’ll find that we generally have well thought out reasons why we’ve done something a certain way and it’s just a case of explaining it rather than…it’s just a case of explaining it to people and I’m sure that will be well understood if people shoot us an email or ask us a forum question or send us a tweet.
[Ken Rimple] – Well listen, thanks so much Ben for taking time with me today to talk about Roo. It’s an exciting project and if you’re a Spring developer and you haven’t looked at it it’s definitely something you should put on your short list.
[Ben Alex] – Thank you very much Ken.
[Ken Rimple] – Big thank you’s to Ben Alex for recording the podcast on Roo. For developers who want to learn more, head on over to springsource.org/roo where you can find links to all the project downloads, forums and blog entries. SpringSource is a Chariot partner.