Play, Roo and a little of Django

12 01 2010

I start my own development and consulting startup-one-man-army company, a risky move on this times, but I hope that will generate profits in this year and in the nexts.

Weapons and choices

As developers, all we have a set of weapons to defeat different enemies, seasoned developers know that non exists a golden hammer, and different problems require different tools, even different mindsets.

Coming from the “Enterprise” world I develop a skills set for kill “big behemoth” projects, my tools include Stripes/Flex/Spring and I’m very comfortable with all them.

But in the small startup kingdom is very hard that you will develop a “big behemoth” projects in the first months or years (until you build a good name for your company), so you will develop small web apps with little requirements, and this is not bad at all, you can make a good profit, if you are smart and have good connections.

But trying to develop a small app, with Stripes/Flex/Spring, seems to be a little… overkill and don’t lie yourself, is possible that you spend a day (even a couple of days) setting the whole enchilada (xmls, libs and all the stuff that you need); this is not the worst thing, (but could be better) in a “big behemoth” with lot of tricky requirements (this tools give you incredible power and flexibility with a reasonable cost).  But in the small apps kingdom a couple of days is too much, and when you realize that you don’t need all the fancy stuff is worst, so I start to evaluate some other options.

The usual suspects

In the Java developer community mindset when you talk about productivity (wherever that means) two names shine among others JRuby on Rails and Grails.

Few years ago Ruby on Rails was the king of the hype, conferences, book, developers of all the world screaming “Java is Dead” and praising his new productivity messiah (wherever that means) whom would lead to the promise land. But them few stories from the trenches show that “The Emperor’s New Clothes” are too invisible for some guys. Right now the RoR community is more mature (or I think so) and Ruby on Rails seems to be good enough, but I think that I’ll wait to the Rails/Merb merge to take a look. In the other hand the JRuby on Rails seems to have less “Rock Star” attitude (Disclaimer: I’m writing this based on the blogs and articles that I read, I’m trying RoR but no more than a few tutorials and no serious project) .

Grails is the Java (or JVM) community response to RoR phenomenon, Grails right now have a lot of momentum and now is under the SpringSource umbrella, with lot of press attention and good community support. Take a look, I say; Groovy is nice language, I say; but, shame on me, I’m not able to run the simplest tutorials, lot of strange (and the worst, non-deterministic) errors spawn everywhere and my confidence in Grails died drowned in a pool of EOF exceptions (and other random things), Maybe in the future I’ll revisited Grails, maybe.

The new kids on the block

So I take a look to other JVM alternatives:


I like Python, is good language, and the Jython implementation is really nice too, a lot of Python libs run very well with Jython including Django.

Django is a very nice framework, extremely well documented, very logical, little or no magic, nice ORM (I don’t like the ORM’s anyway, but this is nice),and have a set of apps (plugins in other frameworks) that let you build a standard web app with little cost.

The Django/Jython integration is very good, and his author (@leosoto) is a smart and nice guy, the main problem for me is his performance; each request represent a small peak in the processor performance, that obviously will be corrected with little hacks in the next versions. Django/Jython is good option to Java developers looking for a good RAD (when I was young the first thing that you think when you read this word was Visual Basic 6, ah the good ol’ times) framework.

Spring Roo

First of all I’m a huge fan of Spring related projects, even I take the Spring Core certification exam and pass with a shiny 94% (seems that I’m the first Colombian with this certification), so my opinion I could be a little biased.

Spring Roo is a project that aims to give productivity (wherever that means) to the Java ecosystem.

Roo have a nice shell interface with lot of options and good documentation, This shell let you to create a new maven project in matter of seconds, all correctly configured, nice start.

Then you can build your entities with the shell (a la RoR) and the horror begins. Roo will generate your class, annotated with Roo annotations and a bunch of *.aj files (AspectJ files) that seems (I’m not expert in AspectJ) that only add methods (getter, setter, toString and some static methods for queries with JPA) to the class (not AOP stuff). I never like code generation tools (if you, like me, try the JBuilder 9-X ($5000) EJB 2.0 app-from-database stuff, you know what I’m talking about), for me is like a glorified “copy-n-paste”. The only valuable thing that code generation tools bring is for teach to junior programmers what is smell code.

But the *.aj code that Roo generate seems to be not bad all, but who know? all the code analysis tools that I know don’t work on *.aj, shame on me. So you can make changes on Java class, but don’t expect that compile outside Roo (or maven), but I’m too afraid to change the *.aj files (one of the worst things of code generation tools) that seems that a dead end road

Not only that, you could generate a CRUD GUI based on JSPX and Spring @MVC (Obviously with all the *.aj stuff), but IMHO, Even with the Spring @MVC (that corrected many things like the horrible inheritance tree) included in the 2.5 version, Spring MVC is by far the most unnecessary part of Spring Framework, if Java have a thing this is MVC frameworks (good or bad), we don’t need another one, PERIOD. For me, used to Stripes, Spring @MVC seems very bloated with lot of code even for simple things. In theory you can make an Add On that build your  GUI in other technology, but theres no documentation right now.

Other thing that I don’t like is that the dynamic client parts are implemented with Spring JS that seems like a Dojo wrapper or something like that, well is pretty hard to know ’cause the documentation is near to nothing (a rare thing in a Spring project).

For me Roo will be almost perfect with a Stripes Add On (maybe I’ll make it in the future) and an option that “push” all the *.aj methods in the Java File… but wait a minute this seems a lot like my “BFG 9000” stack to kill “big behemoth”…. never mind

Play Framework

Play is a mind-blowing/fresh-air for Java ecosystem, totally different from all the stuff that exists in Java.

First of all don’t need a Servlet container to run, or compile, and you don’t see the Servlet API (????) and break some doctrinal rules that all Java developers know (public fields, Model classes extends from a Framework class, strong procedural flavor and others). Those engineering trade-offs could scare some guys, but at the end the framework is very solid

IMHO Play Framework is heavily inspired on Django, but have some things that are more polished that Django for example the absence of Forms (that are a little rough) , the routes seem more polished and the template language is a little more powerful (based on Groovy).

In the other hand, Play don’t have all the modules (apps) that Django have, and of course have less momentum.

In future releases, Play Framework will support Scala as development language, that seems like a very intelligent movement, and who knows maybe we’ll see Groovy, JRuby or Jython as development language (or crazy things like Jaskell or Clojure)

Play is a really good framework and I see myself in the future using Play a lot, (maybe I’ll write a plugin for IntelliJ).


I’ll invest some time on Play Framework in the next few months, but is a community driven framework, so is possible that don’t have the fuel to be a mainstream Framework. In the other hand Roo could be better in a near future with some additions, and have the financial support from VMWare, so is almost guaranteed that Roo will be a success in the middle size projects.




13 responses

13 01 2010
Ben Alex

Thanks for your blog entry about Roo. We’re pleased you like the shell interface and some of the simplifications it offers.

You mentioned performance concerns. Certainly this is one area where Roo will shine, because Roo applications use compile-time bytecode weaving as opposed to dynamic proxies and/or reflection techniques. Roo apps therefore run faster and with fewer resources than alternatives, plus Roo apps have no Roo runtime (meaning no lock in to Roo or Roo runtime stack bugs to worry about).

Concerning Roo’s code generation approach, this emerged following a significant amount of prototyping (as explained in an October 2009 presentation at and my earlier blog entry). This prototyping explored a large number of alternatives to code generation, but none of them satisfactorily addressed all of our design goals (such as no runtime, no lock-ins, good IDE support etc).

Of course some of the alternatives prototyped avoided static source code generation, but the downsides included slower runtime performance, more memory consumption (eg perm gen issues), locking users in, limited/non-existent IDE support, more “magic”, standards non-compliance etc. While sometimes people aren’t worried about such downsides, they are important considerations for many projects and that’s why the Roo code generation model is a good fit in many cases.

You mentioned it would be nice if you could “push in” the .aj code to normal .java classes. As detailed in the “Removing Roo” section of our reference guide at, this is already possible and very easy to do. It only takes a couple of minutes to move all code from .aj files to .java files. However, I’d note that if the purpose is to customise what is generated, Roo already offers a large amount of flexibility in this regard. Roo’s internal metadata model allows it to automatically respond to any changes you make in your project, and its extensible add-on architecture allows you to replace what is generated via your own add-on. Most @Roo annotations also allow fine-tuning of what is generated, but if none of that is suitable you can also move relevant members into .java files and in doing so Roo will automatically consider them as authoritative and cease generating those members.

We take on board the comments about Spring JavaScript. While Spring JavaScript offers progressive enhancement that delivers out-of-the-box client-side validation etc, one of the most popular Roo enhancement requests at present is to offer simplified scaffolded views. We are actioning this in the next major release. In the meantime people are free to edit the JSPs and remove the progressive enhancement if they wish.

Thanks again for your thoughts on Roo. We appreciate the feedback.

Ben Alex
Project Lead, Spring Roo
SpringSource – a division of VMware

13 01 2010
Mario Arias

Hi Ben:

It’s a great honor for me your comments in my humble blog.

My concerns about performance aren’t about Roo, but for Django/Jython, is pretty obvious that Roo don’t have performance impact in runtime.

About the code generation issue, I know that all Spring guys are very talented, and if your choice is this approach, surely you have reasons to do it, just I’m code centric developer, and code generation tools cut my code fun :).

I know that exists and option for push-in (I read the whole documentation) but this option need the STS and I’m huge IntelliJ fan, and I don’t want to install STS just for make this, so Why not make this possible from your very good Roo Shell?

Spring JavaScript maybe is not bad at all, but isn’t documented (the only docs that I found some a pair of pages in Spring Web Flow documentation), so maybe is the framework to rule them all, but I never know if I’m not able to read a nice tutorial.

In the other hand I’m very interested in the possibility of writing a Stripes Add-On to Roo, something like:

stripes -all

and then will generate Stripes ActionBean and JSP’s this is possible? there’s no documentation right now.

Thanks for visiting my blog and I wish the best for your Roo project

13 01 2010
Frederic Daoud

Thanks for posting your comments and observations. Very interesting!


13 01 2010
Mario Arias

Hi Freddy

Good to see you on my new blog.

How is going your new book?

How about a free review copy?, just kidding; I’ll buy your book, when my finances got better. you’re a very good technical writer.

13 01 2010
Ben Alex

Many other people are also keen on seeing IntelliJ support for Roo. The relevant SpringSource project leads (Andy, Andrew and I) have all offered our assistance. The relevant enhancement request for IntelliJ is and as of today it already has 22 votes. Hopefully it will happen soon.

Re Stripes, this would be a great example of a community-developed add-on. People can already use Roo for their middle tier and hand-write their web stack with their preferred framework. Increasingly people are also building web tiers on technologies like GWT and Flex, so Roo support for a diversity of these web approaches is a direction for the next few releases.

Thanks again for your feedback. It greatly helps us prioritise what the community is looking for.


13 01 2010
uberVU - social comments

Social comments and analytics for this post…

This post was mentioned on Twitter by dhaat: @leosoto le podrias dar una leidita?

13 01 2010
Guillaume Bort

Hi Mario,

Great intoduction of the Play!

That’s exactly what we try to build. Something different in the Java world, for those that focus more on the Web that on the Java language, while leveraging all the Java advantages…


20 01 2010
Mario Arias

Hi Guillaume:

Play! is a great framework, I hope that I’ll help to spread the world, and, why not? helping with your code base.

18 01 2010
Derek Neighbors

Always nice to hear about a variety of options. Had not heard of Roo and will be looking into it.

20 01 2010
Mario Arias

Hi Derek:

Variety of options if what make Java and JVM great options for professional programmers.

Roo is a nice plataform, but isn’t for everyone.

19 05 2010

I have to confirm that Groovy and Grails are buggy and have lots of strange bugs. When I first saw Grails, I felt in love with it, but the better I knew it, the more worse it became. I stopped using Grails and switched to Spring MVC, because I wanted to understand what was under the hood of Grails. But Spring MVC made simple things complicated.

Spring Roo seems like the better Grails, but the code generation and annotation magic is a terrible thing! The main problem is the use of a not so powerful language: Java. With Scala much of the strange things of Roo could be avoided.

My favourite web framework is Wicket so far, which has a very clear object oriented approach. Scala and Wicket could be a very good team, if there would be a Scala API leverage the power of the language.

19 10 2010

Dear Mario,

Are you still keen to develop a Stripes Roo add-on?


19 10 2010
Mario Arias


Also I want to develop an Add-on for changing the Persistance Layer to iBatis/Spring JDBC…

But there’s no documentation right now

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: