This week, Artima published excerpts from an interview with Van Simmons about his Jini-based ComputeCycles project. An interesting aspect of ComputeCycles is that it uses Groovy as a configuration language. In the interview, Van Simmons told us how he came to use Groovy for that purpose:

In this day and age, people do these enormous XML configuration files. The Jini design team had that option open to them, but they said, What we really would like is Java configuration. Write a Java class to do configuration, and we'll interpret that on the fly. If you think about it Spring does almost exactly that, does all the configuration, but instead of the configuration files being in Java, [they] are in XML. The Jini team decided to do it in Java...

One of things I've been asking about for a number of years is, How do you enforce security [with Java-based] configuration files? If the configuration files are in Java, what class loader do you load those classes into, and how much access do you give that classloader? And how do you [configure] how much access to give to the class loader loading the configuration?

That's how I came to start thinking about Groovy... Groovy has the Groovy class loader available. And I actually can constrain in its own security context a config file written in Groovy. There is a Groovy-Spring project for replacing all those XML files in Spring with Groovy files. It's the best use of Groovy I have seen so far. You don't have to program your config files in XML any more. That provided an model for using Groovy in ComputeCycles as well.

In addition to an innate dislike of complex XML files, one reason the Jini team opted for a subset of Java grammar as a configuration language for Jini services was that that language enabled the dynamic processing of configuration data. Dynamic evaluation of the environment can be helpful in setting up distributed services, but it also makes the behavior of a service harder to understand, since computed results in configuration scripts affect how services start and operate. The situation is further complicated when evaluating the configuration scripts results in side-effects, such as creating new files and directories, removing directories, or in other ways changing the state of the system.

Increasingly complex configuration may be as much a symptom of complex requirements as it indicates the inability of configuration languages to satisfy the need for greater configuration flexibility. A striking example of how an initially simple configuration mechanism contorted out of proportion is Ant. Ant has evolved into a language of its own, far extending its humble origins in a simple XML file. A cursory look at the set of Ant files NetBeans generates for a default project illustrates this point.

To be fair, Ant evolved into what it is in response to user needs. But something better than XML is certainly needed to configure complex systems. Van Simmons believes that Groovy is ideally suited as a configuration language for Java-based systems, since Groovy code easily interacts with Java objects, and is also less verbose than a Java subset, such as the configuration language used for Jini.

In your experience, what are the requirements for an ideal configuration language? What languages and configuration mechanisms have you found friendly, but still flexible, in your projects?