Ruby on Rails was the first significant Web application framework to favor convention over configuration: By following a large set of sensible defaults in every Web application layer, developers can get a Rails application up and running very quickly.

Rails' approach has been refreshing to Java developers fatigued by the need to rely on complex XML files to put even the simplest application in place. Although Java EE 5's use of annotations has reduced the need for explicit configuration, other Java frameworks go even further in embracing conventions in place of configuration.

One such framework is Grails, which, as its name suggests, is heavily influenced by Rails. Using Groovy instead of Ruby, Grails attempts to tie together Java technologies as diverse as Hibernate, Spring, and Sitemesh into a coherent whole.

Jeff Brown's recent article in Object Computing's March issue, Introduction To Grails, provides a quick introduction to Grails, including an tutorial example Grails application. Brown notes that:

Coding By Convention results in very little configuration being required in a typical Grails application... For example, in a Grails application a typical HTTP request will be handled by some controller and the controller will then render some view back to the client. There is no configuration file necessary to map a request to a specific controller and no configuration file is involved in deciding which view corresponds to that particular request. All of that can be managed by following some basic conventions.

Brown shows how Grails' Rails-like command-line generators can create a basic application scaffold:

Grails provides a number of command line actions that may be invoked as arguments to the "grails" command. The command to create a new application is called create-app. The create-app command accepts an argument that is the name of the application to be created.

The article also walks through a basic example using Grails' object-relational layer for persistent domain classes, Groovy Object Relational Mapping, or GORM:

In many ways a Grails application revolves around the domain classes (also known as model classes)... These are the things that are typically stored in the database... A Grails domain class may also declare validation constraints to help impose business rules. Validation constraints may be added to a domain class in the form of a static closure property named "constraints".

The [following] method ... invoked here is one of the many dynamic methods that Grails adds to all domain classes:

def list = {
        if(!params.max)params.max = 10
        [ personList: Person.list( params ) ]
 }

This closure is returning a Map that has 1 entry in it. The key for that entry is personList and the value associated with that key is a list of Person objects returned from the Person.list(params) call. [The original] Person class did not define a list() method.

Many of Grails' most code-reducing features seem to be the result of Groovy language features, such as closures. That's similar to how Rails makes good use of Ruby features, such as the ability to add methods to a class at runtime.

To what extent do you think Java applications' more involved configuration requirements are the result of Java the language? What Java language features do you think would help build more dynamic Web frameworks in Java?