Groovy and Grails at JavaOne

Hello from San Francisco! I am at JavaOne this week. Catching up on what is new, important and at issue with Java. The conference is not cheap and travel is usually one of the first things that go in reduced budgets, but if you can somehow manage it, this is the conference that all Java developers need to attend whenever possible.

The conference’s Java University started today. I attended a wonder class by Graeme Rocher on Groovy and Grails. Graeme is the project lead for Grails and head of Grails development at Spring Source.
Groovy is a programming language that has been attracting a lot of attention lately. And base on what I learned and saw today, it rightfully should. Groovy is a dynamic language inspired by a number of other such languages (most notably like Ruby, Smalltalk and Python) written specifically for the Java Virtual Machine. Its aim is to bring the “power of Ruby and Python and the elegance of the Java syntax to a JVM.” Because it is written specifically for the JVM, it is an extension to Java. Groovy provides all the power of metaprogramming but with all the benefits of Java and the JVM underneath. Although other dynamic languages like JRuby or Jython run on the JVM, they have had to be modified in order to run on the JVM. Some concessions were made in the port of Ruby and Python to the JVM. Most of the environments are an extension but a replacement of the Java API (having their own I/O and collection API for example). The goal of Groovy is simple – less code meaning faster development and hopefully easier/faster maintenance.
Grails is an MVC++ action-based web framework. Grails is to Groovy what Rails is to Ruby (more precisely Ruby on Rails). I say Grails is an MVC “plus plus” framework because it is more, way more, than just a web application framework. It also provides the entire platform for building applications from the UI to the data layer. In fact, Grails is built on Groovy (of course) as well as Spring, Spring MVC, Hibernate, Quartz (for job scheduling), SiteMesh (layout framework), Jetty and HSQLDB. Like Rails, building a CRUD (create, read, update, delete) interface can be done in minutes. But because it is also built on top of the best-of-breed Java technologies, it can also do so much more, and because it is done with Groovy, it can be done quickly with very little code.

A couple of things to consider before you start singing Kumbaya with the Grails/Groovy crowd. Grails requires a relatively up to date platform. Grails comes with its own container and even database, but most shops are going to want to run Grails on their own container. Grails requires a Web container that is at the 2.5 level (Java Servlet 2.5). Secondly, Grails is slower than Java. According to Graeme, he has seen a Java application that did ~1000 transactions a minute only perform ~750 when using Grails. The good news is that the same app using Rails did only ~150. Rails performance issues are starting to attract some attention and Grails offers the same kind of development convenience with a much better performance outlook (see http://www.infoq.com/articles/Rails-Performance or http://www.techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/ for some of the Rails issues). Lastly, Grails, while offering the promise of less code and faster development, is not a tool for novices. Under the covers of Grails and Groovy, there is a lot of Java and Java technologies. While Groovy and Grails helps abstract away many of the details and common drudgery of modern Java application development, it does not protect the developer from having to fine tune and tweak application to do the business’s bidding, especially in large scale, high performance environments. I asked Graeme if he felt developers of Grails applications needed to know Spring, Hibernate and all the underlying technologies well to be able to build a large scale performing enterprise application. He indicated that in some cases, for example Spring, developers were isolated from having to know the framework to get things to work and work well. But developers are going to have to know and understand the inner workings of other frameworks like Hibernate in order to make parts of Grails like GORM (Grail’s ORM capability) perform well. Given that Grails is built on top of Java, on top of many Java technologies like Hibernate and Spring, and on top of Groovy, this is a lot to learn and know.

Still, when you see the simplicity and speed of Groovy and Grails development, you can’t help but believe there indeed IS a better way to build Web applications. “Power to the people” with Groovy. I encourage you to take a look. More information on Groovy can be found at http://groovy.codehaus.org/. Information on Grails can be found at http://www.grails.org/.