Dispatches from Andyland "Your reality, sir, is lies and balderdash and I'm delighted to say that I have no grasp of it whatsoever!" — The Adventures of Baron Munchausen

February 14, 2007

Java-based rapid development web application frameworks

Filed under: Uncategorized — Andrew @ 12:20 am

I spent some time looking at Java web application frameworks that claim to provide rapid development. In unfairly condensed terms, the “Ruby on Rails for Java” sort of frameworks.
I looked at Roma, Trails, and Grails. I sort of played around with each a bit. Going through their introductory tutorials and trying a few things on my own. I probably continued until I got annoyed or lost interest in that particular package. That might not be the way to give a fair assessment, but it was about as much time as I was willing to give to any package. (sometimes something worthwhile takes a little bit of effort, and you have to go beyond where things start feeling comfortable. For example, if my attempts at exercise went beyond the times where I got bored and lost interest, I’d probably be thinner.)

None of these packages intend to be a direct port of Ruby on Rails, but all to some degree make comparisons of their product to Rails.

Many of these packages are based on other Java frameworks. The Spring Framework is a very common one. It seems reasonable. Spring’s Inversion of Control and Aspect Oriented Programming features are useful tools in extending software in was that the developer wouldn’t realize that it was being extended. This would sort of make up for the dynamicism of Ruby that helps make Ruby on Rails work well. All of them use Jetty as an embedded web server for testing.
All use Hibernate as a Object Relational Mapping system. This implies that for most, the domain objects are used to build the table structure. (As opposed to Ruby that dynamically gives an object properties based on the current database schema.) It seems to make sense under the circumstances. The Java type system is richer than the SQL types of most RDBMs, where the inverse is true for Ruby. One can ignore data in a stronger type system to connect to a weaker typed system, where inferring types that don’t exist is more difficult.

The Roma framework is based on pluggable aspects that get enabled on a project. If you want a AJAX based on you run “roma addModule aspect-view-echo”, supposedly if you want a component based view you run the command “roma addModule aspect-view-jsf” (except for the fact that echo2 is the only view module developed so far.) Other modules like persistence, monitoring, and connection pooling can be added on as modules.

With the only existing view aspect that is developed for Roma is a high feature AJAX one, it implies that views aren’t just scaffolding like they are for Rails. They are expected to be (perhaps the starting point) of the final web pages. The components themselves can control how they are displayed (strings output HTML text boxes, Date fields have a popup calender box, etc.)

I had some annoyance in the way Roma handled paths. The command “roma createProject” will ask for a path and create a project directory. It also makes it the current project and all further commands are directed to that project until you execute “roma switchProject”. I’d rather run the commands from the project directory and have them affect that project. (I tend to have multiple projects created and being worked on simultaneously, and wouldn’t want to worry about which one is current.) There were also scripts within the project directory, for example to start and stop the web server, which needed to be run with certain relative paths. (

I was working through the tutorial about to the point where some buttons were supposed to appear but they didn’t. I found on their forum that it was a bug and and would be fixed in a later release. I figured if they could break the most basic functions in their introductory tutorial with a release, I’d worry about the stability of the whole thing and it was time to look at what else was out there.

The next one I tried was Trails, started running through its tutorial and probably started at about the same frustration I left off Roma with. The major issue is that Trails recently switched from being built with Ant to being built with Maven, and the tutorial was written based on the Ant version. I can see why they would want to use Maven; Trails has many dependencies. (For Perl developers unfamiliar with Maven, picture it was having the dependency resolving features of the CPAN shell, the layout standardization of h2xs, and the standardized build steps of ExtUtils::MakeMaker or Module::Build.) Perhaps too many dependencies. It has both Spring and HiveMind as IoC containers, Spring and AspectJ for AOP environment. It has hibernate-hivemind modules, tapernate, as well as spring-hibernate modules. I admire them for not reinventing the wheel, but you could think they could choose a few good wheels out of all of the wheels on the lot.
The most noticeable problem with following the old tutorial with the latest code is when it says to execute something like ant create-edit-page to customize the default HTML output. Most of the project unique build steps are removed in Maven. It isn’t too tough to do, but I had to look at the Subversion archive to find the old Ant build.xml to find out that ant create-edit-page just copied DefaultEdit.html to ${classname}Edit.html. Trails’ use of Tapestry for the display is nice because it is component based views rather than page based views.
What eventually turned me off of Trails however was the lack of some sort of controller component. This will turn certain code wind up in the domain classes where I wouldn’t have put it there otherwise.

The last one I looked at was Grails. Grails, uses the Groovy interpreter for the domain classes. The GORM module eases the creation of domain class to hibernate and SQL mapping. (most of the other packages I mentioned use the Hibernate annotations.) A controller class can be as simple as def scaffold = Book but can be anything beyond that can be as complicated as you want it to be. Since the classes can be Groovy, you have many of the advantages of a dynamic interpreted language. It seems to me to be the easiest to quickly create applications. Scaffolding is built to get an idea of how the whole application is working end to end, but all of the scaffolding is replaceable when it is time to build something beyond the initial CRUD scaffolding.

The biggest drawback I can see is that it if you are looking for a Rails alternative because someone said they wanted Java and not Ruby on Rails, a Groovy based solution probably won’t be acceptable either. (It depends on why the requirement for Java though. If it is because someone wants the ease of deploying WAR files on a cluster of application servers, or wanting to integrate with other Java components, a Groovy based solution may be OK.)

4 Comments »

  1. Other good reasons for using Grails include: you can can write code in Java too, not just Groovy. You can integrate with minimal Groovy code your existing Java hibernate entities or EJB beans/services, and you can leverage all those tasty Java libraries out there with zero pain :)

    Comment by Marc Palmer — February 17, 2007 @ 3:31 pm

  2. Stripes is posibly the only MVC type -user interfaceless- rapid developement tool. it has alomst zero configuration and very few code. Otherwise Seam is your guy.

    Comment by afsina — February 22, 2007 @ 8:20 pm

  3. Limiting yourself to RoR clones could be a bad move. Take a look at http://www.webfastforms.com if you want something different.

    Comment by Tony Marston — February 23, 2007 @ 4:34 am

  4. aaah, is there an update to this?

    Comment by Dai — March 1, 2009 @ 5:00 pm

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress