Many Web development frameworks took inspiration from Rails' simplicity and productivity since the Ruby-based framework appeared four years ago. One such framework is Grails: based on the dynamic Groovy language, Grails provides many of the metaprogramming techniques that make Rails development so productive, but Grails applications run on the JVM and can very easily incorporate existing Java libraries and code as well.

In the initial article of his IBM developerWorks series on Grails, Mastering Grails: Build your first Grails application, Scott Davis introduces the framework, and goes through a complete example of creating a Grails application:

Rails ... presents Java developers with difficult choices. Do you abandon the familiar Java platform for the promise of a new one? And what do you do with your existing Java code, your existing production servers, and your staff of seasoned Java developers?

Enter Grails. Grails gives you the development experience of Rails while being firmly grounded in proven Java technologies. But Grails isn't just a simple "me too" port of Rails to the Java platform. Grails takes the lessons learned from Rails and mixes them with the sensibilities of modern Java development. Think inspired by, not translated from.

Davis highlights several Grails features that are enabled by the Groovy language:

Just as Rails is deeply tied to the Ruby programming language, Grails wouldn't exist without the power of Groovy... Groovy allows you to reduce dramatically the amount of Java code that you would normally write. You no longer need to write getters and setters for your fields, because Groovy provides them for you automatically. No more writing for Iterator i = list.iterator() to loop through a list of items; list.each does the same thing more concisely and more expressively. Simply put, Groovy is what the Java language would look like had it been written in the twenty-first century...

While Davis presents Groovy as an improvement to Java, he also points out that Java is source compatible with Groovy code:

Groovy wouldn't be nearly as appealing to Java developers if it forced them to rewrite entire applications from the ground up to take advantage of it. Happily, Groovy seamlessly integrates with your existing codebase. Groovy doesn't replace the Java language—it's an enhancement. You can quickly pick up Groovy because at the end of the day, Groovy code is Java code. The two languages are so compatible that you can rename a working .java file to a .groovy file — for example, change Person.java to Person.groovy — to have a perfectly valid (and executable) Groovy file (albeit one that doesn't take advantage of any of the syntactic sugar Groovy provides).

One of the nicer features of Rails is that the code distribution comes with a fairly complete environment to start working with. Grails offers a similar benefit, according to Davis, including a Web server as well as the HSQLDB Java relational database:

You don't need a separate Web server installed to run Grails applications. Grails ships with its own embedded Jetty servlet container. You type grails run-app to get an application up and running in the Jetty container (see Resources) without needing to hop through the usual deployment hoops... Running a Grails application on your existing production server is no problem either. Typing grails war creates a standard file that you can deploy to Tomcat, JBoss, Geronimo, WebSphere, or any other Java EE 2.4-compliant servlet container... You don't need to have a separate database installed, either. Grails ships with HSQLDB (see Resources), a pure-Java database.

The remainder of Davis' article shows how to create a Grails application with the help of a scaffold generator, and explores the different application components a Grails application defines by convention.

What do you think of Grails? Where would you position Grails in the spectrum of Web frameworks that run on the JVM?