Grails 1.0 has been released, and announced on the project mailing list, Graeme Rocher's blog, and on Grails.org. InfoQ spoke with Graeme Rocher, Grails project lead and co-founder, and CTO of G2One about the release of Grails 1.0 to deliver in-depth coverage about the feature-set, maturity, ease of use and future plans for Grails.
The Grails 1.0 release notes page itemizes the new features in detail, but these include:
- ORM DSL, which can reduce the need to fall back on Hibernate mappings when working with legacy tables.
- Easy to use Filters, which can be applied to specific actions, to an entire controller or across multiple controllers based on URI.
- Support for building REST services.
- Content Negotiation support, often used to allow easy switching between HTML, XML, JSON and other such representations.
- Automatic XML/JSON Unmarshalling to support submission of data via XML or JSON, which can be important for web services and RESTful approaches.
- Scoped Services, which allow for different programming models for storing state in services.
Grails is also taking advantage of some of the Groovy 1.5 features such as annotations:
[W]ith 1.0 you can use JPA style annotations (currently only supporting mapping with Hibernate) as opposed to GORM if you prefer that approach.
You can also leverage all of the Spring annotation support such as <tx:annotation-driven>.
Although a 1.0 release is simply another release of a software project that has had many, it is both psychologically significant and a vote of confidence by the project team.
As Marc Palmer said:
Most people understand that psychologically a 1.0 release is important. It sets the baseline and foundation for what is to come in the future. Grails 1.0 is incredibly rich in terms of core features, and has a growing list of free plugins that add all manner of powerful functionality.
When asked to address the maturity or 'readiness' of Grails, Graeme Rocher said:
With confidence that it is [mature/ready]! Seriously though, there has never been a software release without bugs, and if a software vendor says their software has no bugs they're lying. What I can say is we've taken the time to get it right, Grails has been nearly 3 years in the making. We are confident that when people try Grails they will enjoy using it.
Enumerating some of Grails' success stories, Graeme started with those listed on the site, but added that:
Grails' main area of penetration has been in the enterprise which is a bit more difficult to just point out or even talk directly about.
For example Grails is being used by major French broadcasting companies, a major US hosting provider and top HR companies in London. In addition SAP have their Composition on Grails project which allows you to quickly build composite applications on SAP NetWeaver 7.1.
Grails is also based on a mature stack, from the Groovy language (which has recently addressed the issue of enterprise readiness, Spring, and Hibernate. Graeme added, "Would you regard Spring and Hibernate as risky?"
Graeme talked about some of the reasons why Grails has seen good uptake in the Enterprise:
Grails is much easier to digest for large enterprises with existing infrastructure often built on Spring and Hibernate.
This is down to a number of reasons, one of them is that we have made it pretty easy to re-use existing Spring bean definitions by simply dropping in the necessary XML (probably the only time you have to look at XML in Grails!).
It is also trivial to re-use existing Hibernate domain models whilst still getting all of the benefit of Grails.
Continuing to talk about the ease for development teams to get up to speed on Grails:
Since Groovy is designed from the ground up to integrate as smoothly with Java as possible at the syntax level it is certainly much easier for a team of Java developers to get up to speed with.
Grails itself is all about dramatically simplifying Java EE, because to be honest the majority of frameworks that exist for Java are just way harder than they need to be. This makes it harder for software engineers from other platforms to come to the Java platform due to the huge jump in complexity.
In this sense Grails is actually opening doors to the Java platform for developers from other communities such as PHP.
However, that ease of adopting a full Java stack can occasionally come with a price:
As for the dangers, the main one is really that we've done such a great job in abstracting the underlying frameworks that sometimes this can leak.
For example if you don't understand the different between lazy and eager fetching in Hibernate you can get yourself in trouble. However, these dangers are not really any different to any other Java project, its just that its so easy that newcomers to the framework sometimes fall into this trap.
Some people have concerns that dynamic languages may make it easier to do initial development but at a higher maintenance cost later, due to less-effective tooling. Graeme responded to those concerns as follows:
Groovy I strongly believe is different. There are a few reasons why I believe this is the case. The first is that Groovy is not dynamically typed, but optionally typed meaning that you have the choice to specify the type or not and in most cases the type can be inferred. For example using something like IntelliJ's JetGroovy plug-in you have full refactoring and code analysis support for Groovy almost to the level of Java.
Even better is that because Groovy is a true mixed source language with a joint compiler, you can easily navigate from Java to Groovy and back again. Whilst with other dynamic languages I feel you lose much of the code analysis and refactoring capability of Java, with Groovy this is not the case, making maintainence not that different from Java.
I hope that over time the Eclipse and Netbeans support reaches the level of IntelliJ so that more developers can be exposed to this type of development.
Looking forward into the future of Grails, Graeme talked about the plans for releases beyond 1.0, starting with Groovy 1.6 and performance:
1.0 is about setting a benchmark for backward compatibility. From now on whatever new features we add will be very much keeping in mind existing applications and so forth.
There will inevitibly be a few 1.0.x releases, however for 1.1 there are a number of things we are focusing. Firstly, Groovy and Grails' roadmaps are very much inline with each other, so one of the big things coming for Groovy 1.6 which will be included in Grails 1.1 is massive improvements in performance using call site caching techniques.
The aim is to get Groovy inline with some of the fastest dynamic languages on the JVM, this will only benefit Grails, which already scales very well thanks to being built on solid foundations. As for Grails itself the main thing on the agenda is further integration with Java EE technologies and projects.
Marc Palmer also talked about a new kind of integration testing with real applications that will be used on Grails 1.0 and beyond:
We have also put together a framework for automatically running functional web tests on "specimen" applications held in SVN as part of the Grails continuous integration builds. There are some teething troubles with the server environment but the whole process is working locally, and we just need to fill SVN with some good test apps with, more importantly, some comprehensive webtest scripts.
This will effectively form a kind of "TCK" for Grails and will ensure stability against the 1.0 baseline functionality - in addition to the large number of unit tests that Grails undergoes constantly as part of the continuous integration build platform (the rather excellent Bamboo as it happens). Contributions of non-trivial applications with comprehensive unit and webtests would be appreciated.
Grails will also continue to integrate new technologies from the Java space, striving for the goal of full-stack integration and aiming to be one of the top web frameworks for Java:
For the 1.x releases we plan to add JPA, JSP tag library and Portlet support as well as integrations with other popular web frameworks such as JSF, GWT, Wicket and Struts through plug-ins. In addition, we plan to include Maven 2 support out of the box with Grails through a Maven 2 plug-in that hooks Grails into the Maven life cycle. Remember Grails is not just a web framework, but a software stack which aims to solve every part of the software life cycle from the build system to the ORM layer.
Although Graeme admitted that any plugin system may have problems where one plugin and another don't co-operate, he talked about some of the more popular plugins:
There are some plug-ins that have really taken off and have a good growing community around them. For example the JSecurity, Searchable (Compass integration), XFire and RichUI (Yahoo UI integration) have provded very popular and continue to grow rapidly.
Others are progressing at a slower rate, but there are very few "dead" plug-ins which is a good sign.
And, finally, October 2007 saw the formation of G2One, which provides training support and consulting for Groovy and Grails:
Since we launched in October we have been doing phenomenally well and have doubled in size. It has been excellent for Groovy for example, which has seens it issue resolution go through the roof
We now have multiple people working either full or part time on each project and it has also made a big difference to those who were considering adopting Groovy, but were looking for support.
Reactions from the community have started to trickle in from Jaiku to blogs, and although many of these contain the simple facts of the release, some of those reacting have had some experiences with Grails to share:
-
Michael Kimsal has been looking forward to this release:
I haven't been this excited about a tech release in ages ... Grails has certainly come a long way since I started right around the .5 release last spring. Graeme and the gang have been working like, well, gangbusters to work through many of the outstanding bug issues, fixing hundreds of issues in the past few months to get 1.0 out the door.
-
Meanwhile, Ray Kreuger suggested that Java developers give Grails a closer look:
If you're a Java person and aren't familiar with Grails or Groovy for that matter, you should definitely check out Grails. Grails is a rapid web application development framework based on convention over configuration. It is designed MUCH like Ruby-on-Rails, but built using Groovy as a language. The main benefits of this approach is that Groovy is based on Java; which means it looks and feels like Java. This helps introduce it to a team and lower the learning curve. The other benefit is that it builds down to a WAR file that you can deploy into any old application server. No special hackery required. This is important when deploying it into a very 'enterprisey' environment.
-
Bill Gloff suggested you don't take his word for it, but try it yourself:
A lot of excitement is building up around Groovy and its counterpart web framework Grails these days and I see why as its fun to use and you become way more productive as a developer. Grails takes a lot of cues from Ruby on Rails but also gives the ability to leverage your existing Java knowledge and JEE environment.
-
GroovyZone advocates for Grails:
For me Grails is the ultimate rapid prototyping platform for Java. I've built numerous applications by dropping in existing Hibernate-configurated classes and generate scaffolding views. It gets you started really quickly and helps you to focus on the application you're building.
-
Finally, a recent controversy comparing Rails to Grails may help those who might like to understand how these two compare:
- Darryl West suggested 10 Reasons to Switch from Rails to Grails
- Graeme Rocher followed with Grails Making Java Developers Forget about Rails
- Relevance, known mostly for their Rails work, filed Graeme's points into 'reasons to switch', 'edge cases' and 'crap'.
- Jens Krämer argued that Graeme's just looking for attention for Grails.
InfoQ will continue to cover Groovy and Grails as the story progresses.