Grails is an open source Java framework for creating web applications.The Grails framework attempts to bring some of the lessons from Ruby on Rails into the Java world such as DRY (Don’t Repeat Yourself) and Convention over Configuration. Grails gets most of it’s magic from Groovy, a scripting language that is targeted to the JVM and features a mix of static and dynamic typing, and a Java like syntax. Groovy scripts are compiled to Java classes and can import regular Java classes (and vice-versa), so you can leverage your existing libraries. Grails feels a lot like a Rails framework. If you want experience the power of Rails but don’t feel like learning Ruby (shame on you)-then try Grails. On the other hand, if you have spent any time with Rails, you will find Grails simple to learn (especially with a Java background.
Scott Davis gave the Grails tutorial at OSCON. He began by addressing the fact that the Java community has lost some very influential/visionary people to the Ruby camp over the past couple of years including James Duncan Davidson (the creator of Ant, Tomcat), Martin Fowler, Tim Bray and Dave Thomas. He didn’t really spend much time discussing whythese folks are so fond of (and in many cases prefer) Ruby. Davis decided to embrace Grails and Groovy because he disliked the context switching from Java to Ruby, and felt Grails offered benefits from both Rails/Ruby and Java worlds.
Some of the key differences between the Rails and Grails web frameworks include:
- Groovy: As mentioned, Grails uses the Groovy scripting language on top of various Java libraries such as Hibernate. Rails is written entirely in Ruby, although Ruby code can invoke C and Java code depending on whether you are using the Ruby or JRuby interpreter. Whether Groovy is as elegant (and productive) as Ruby remains to be seen.
- GORM (Grails Object Relational Mapping): is used in Grails to map domain objects to their corresponding database table. GORM is written in Groovy, but under the hood, it’s using Hibernate 3. GORM objects look and act very much like Rails’ ActiveRecord objects. There is no explicit mapping required, and table associations are simple method calls inside the domain object (belongsTo(), hasMany(), etc). In Rails, the ActiveRecord class treats the table as primary, and derives the model classes dynamically based on these tables. GORM does not. In GORM, you must explicitly add attributes to the model class file (it’s a groovy script). Once this is done, GORM will use Reflection to determine which database column to map each attribute to. In fact, it will create the table and columns automagically (at least, it will in development mode).
- Choice: A Rails project doesn’t tend to offer a lot of choices with regards to it’s underlying components. For example, you use ActiveRecord for your ORM and Rake for your build scripts. Part of the reason for this is that these tools tend to be very good and-thanks to Ruby-tend to be very easy to extend. The Java community tends to have an overwhelming number of frameworks, application servers, views (JSP, Velocity, Tag Libraries, etc) and libraries to choose from. While there are pros and cons to having so many options, the bottom line is that you get choice with Grails. Here are a few of them:
- Grails projects are wrapped up as ordinary WAR files, allowing you to deploy them into any J2EE compliant web server. **nb: The JRuby interpreter allows you to do the exact same thing with a Rails app assuming you aren’t calling native C functions.
- Grails uses Hibernate 3 for persistence, but will also support JPA compliant technologies such as EJB3.
- Grails supports both GSP (Groovy Server Pages) and JSP as view technologies.
- Community: If there was one thing I learned at OSCON, it’s how vital the community is to the success of an open source project. Grails is targeted at Java developers (a very large community indeed). But it is basically a copy of Rails. On one hand, I admire this because the Grails developers weren’t afraid to acknowledge that another community/technology has done something really well. On the other hand, is wonder whether the Groovy/Grails community is going to be as innovative? The Ruby community has a ton of well earned mojo going for it right now. It is really popular at the grassroots level. And big companies like ThoughtWorks and Sun have taken notice. Sun and Thoughtworks officially support Ruby via the JRuby project (and ThoughtWorks claims to be doing 40% of their work in Ruby). So you have a groundswell of young developers who want to write Rails apps, and corporations in the Java community pushing Ruby for the enterprise. I asked Davis about this, and he felt the neglect of Groovy and Grails was because corporations like Sun were trying to win back the Ruby developers who left the Java world. I’m sure that’s part of it, but not the whole story. I think Sun have realized that the Java language is not the answer to every problem.