Grails 2.0 Released with Improved Usability, Class Reloading, and Query DSL

The Grails development team at SpringSource, a division of VMWare, recently announced the release of Grails 2.0. This release improves Grails usability akin to Roo console. The advanced class reloading works for Groovy and Java. GORM, the persistence layers in Grails, maximises the DSL support from the Groovy 1.8 via AST transformations.

Graeme Rocher, Grails lead developer and inventor, wrote the official announcement yesterday.

In this announcement he mentions that this release was the culmination of a year's work. This release enhances the user experience with cleaner debugging support and a console app with code completion reminiscent of Roo, another SpringSource project with similar goals but Java centric.

The new features include:

1. Console with tab completion and colored output
2. More reliable class reloading mechanism, giving Grails more of a PHP feel of refresh the page and things just work
3. Better debugging support with enhanced error reporting and more accurate problem diagnosis
4. Library updates Groovy 1.8, Spring 3.1, Hibernate 3.6 and Servlet 3.0
5. Framework for delivering static resources (CSS, Javascript, etc.) to aid in Grails plugin development so for example the same JavaScript library is not included on the same page more than once by several different Grails plugins
6. New APIs for link generation and page rendering
7. New GORM features: detached criteria, Where queries, multiple data sources that use Groovy AST to provide DSL catered to the task at hand with type checking support
8. Improved unit tests that can use Spock, JUnit or TestNG
9. Database migration plugins
10. Improved database reverse engineering
11. and much more

Opinion: When looking at the detached Query DSL and the where method queries DSL from GORM there is little doubt that Groovy AST transformations aids in Groovy DSL development. With the Groovy 1.8 release, Groovy has become a first class, DSL-ready language. GORM shows off Groovy's DSL support well.

InfoQ got a chance to catch up with Peter Ledbrook, Grails Advocate. Peter is a worthy advocate since he worked at G2one, the Grails Company, prior to Spring acquiring G2One. Peter has been working with Grails since 2006 when it was originally called Groovy on Rails.

InfoQ: What are the major changes from the last version?

The most immediate change that people are going to notice is the new interactive console, there is a little screencast that shows that. It basically has the auto tab code completion, history buffer, syntax highlighting, and because it is a running JVM all the commands run that much quicker since you don't have to load Java and initialize Groovy for each command. Another benefit is our class reloading which is done by a JVM agent. We always had reloading, but now it works more reliably and for more things. It now works for domain classes. Restarting the servlet container will become much less frequent for users.

He went on to discuss improvements in the test framework and static resource delivery to simplify Grails plugin development. The added unit test flexibility allows JUnit, Spock, TestNG and other frameworks more readily. The unit testing has a GORM emulation to test database access without hitting the database. Both Roo and Grails console support and class reloading support benefit from JVM reloading agent which is part of Spring Source tool suite.

InfoQ: What cloud support does Grails have for CloudFoundry, Amazon EC2 and Google App Engine (GAE)? Does it support EC2 out of the box?

There is no in core support for cloud. But, it is very easy to add through various plugins. CloudFoundry, for example, we have first class support. There is a VMC tool for deploying, but we have a plugin that does almost everything that the VMC tools does, but it also have awareness of grails replication. It knows if you have the MongoDB Grails plugin installed so it can check when you deploy that you have a MongoDB service provisioned in CloudFoundry and bound to your application. It will actually ask you if you want to provision and bind a MongoDB instance. That is very useful. Your app does not have to be CloudFoundry aware.

He went on to discuss an Amazon WS (EC2, S3 et al) plugin that supports easy access to Amazon services like messaging, storage and more. It does not support deployment to Amazon. He went on to discuss ways to use Groovy config files to access properties configured in Amazon BeanStalk to facilitate quick deployment to Amazon using BeanStalk.

Then he spoke about Google App Engine support. There is a GAE Grails Plugin, and you can deploy to GAE. But there is some work that needs to be done to GORM to support Google's flavor of JPA. The deployment to that platform needs some work.

Tangentially he mentioned that there is work that needs to happen on GORM's JPA support in general. The current GORM JPA adaptor supports JPA 1.0. It needs to be updated to support JPA 2.0. By supporting JPA 2.0, in effect, GORM would support a lot more persistence solutions that are built on top of JPA 2.0.

InfoQ: What are the major changes to GORM? and is GORM a standalone project? Could I use GORM with a non-Grails project?

There have been quite a few enhancements there. One of the most noticeable ones is that you can use GORM against several alternative datastores, the NoSQL datastores. We released the latest versions of the MongoDB and Redis plugins. There are others coming along. People are able to use a standard API for accessing this datastores.

We also introduced a new query syntax that I would expect to take over from dynamic finders and criteria API as well. We call them where queries. You use the method where, but it is really good for Java and Groovy developers because you use the standard notation. You use the Groovy/Java equals operators and equals and greater than, in a way you would in code using logical operators as well (&&, || and more).

There where method look like a SQL/Java/Groovy custom DSL, and InfoQ quizzed Peter at length how this was accomplished. To sum things up, the where method syntax uses Groovy AST transformations so you have a DSL query language that the compiler can do type checking and more compile checks in a very natural way. It more than just a string. It is part of the language via an AST transform. The where use of transformations is very similar to what is done with the Spock test framework. It looks very cool and magical. Peter mentioned that there is some very interesting stuff they can do with Groovy AST transformations.

GORM that ships with Grails 2.0 ships with Redis, Riak, and MongoDB NoSQL support. There was also community contribution for Neo4j.

InfoQ: Is GORM a standalone project?

Yes and no. Now much of it is implemented in series of Grails data mapping projects, which basically sit on top of the Spring Data project. Those you can use directly. You can use GORM for MongoDB outside of a Grails application.

GORM for Hibernate probably needs some more work. There is some GORM code in Grails itself. When some people talk about using GORM outside of Grails they are talking about GORM for Hibernate. We need to do a little bit of work there. Most of new GORM features are in separate projects.

InfoQ: How would you update an older application to Grails 2.0?

For several projects, it is pretty much just run grails upgrade command. There are some breaking changes that have been documented, but they are straightforward. You may have to add a configuration setting. You may need to add a template. If you want to use the Grails 2.0 unit testing framework, you will need to go all in for new tests. This may require a fair bit of work.

More importantly outside of Grails core, we did a good job of making sure that critical plugins were up to date. There are many many plugins out there so there may be some that still need updating. We will try to work with Grails plugin authors to make Grails plugins Grails 2.0 compatible where necessary.

InfoQ: How is Grails adoption going? Are you seeing increased adoption? Do you feel more people are using it?

Definitely. There is more traffic on the mailing list. There is more anecdotal evidence of people using Grails. More mentions on twitter and that kind of thing. There seems to be more people speaking about it.

One of the interesting things that I have seen is people coming from a PHP background to Grails. That sort of helped us to change our perspective. Grails is not just for Java developers, but should make the Java platform mores accessible for people not from a Java background.

In looking at Indeed.com, there seems to be a lot more job demand for Grails developers. Perhaps a factor of ten increase in the last two years.

InfoQ: What do you think of similar projects like Roo, Rails, and the Play framework? Any recent cross pollination of ideas? Do you see similarities? Any comment about any related frameworks?

There has been cross pollination for a while. And certainly Rails has always had a strong influence on Grails from the beginning. I am not sure if there is anything recent. For example, our static resource support was done independently from some similar features in Rails. But we implemented it, and then realized that Rails had implemented something similar. It was interesting and some people probably thought that we borrowed the idea.

Although, we are not averse to borrowing good ideas. Certainly, Spring Roo interactive console had a lot of influence on ours and showing the benefits of that. Especially when dealing with Java based systems. We do keep an eye on other frameworks. It is difficult to say what is active borrowing versus just being aware of these things that are happening like how REST support is being done. Then that happens without being explicit. Much of the new stuff is quite inherent to Grails. Particularly around the GORM features. Quite possibly there are some feature request from users that came from other frameworks as well, but we don't necessarily know of these.