While various Web frameworks devote lots of attention to making complex systems easier to build, most frameworks default to using a flavor of XML to specify how those complex systems are configured. A few projects started to innovate in the configuration space, but the requirements for an ideal configuration solution are still to be defined.
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?
> <p>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.</p> > The issue of Groovy is that the language is not quite widespread, and not stable enough yet. Plus it doesn't put enough emphasis on domain-specific languages, which are very interesting for configuration files or behaviour scripting. It's only advantage is that it does quite look like Java, but that's pretty much everything it has running for it.
I think the best configuration language right now would probably be JRuby: it can interact with Java object, it's much less verbose than Java, it inherits Ruby's strenght with DSLs and it seems fairly stable and complete already (probably not perfect, but seems on the way).
Plus JRuby also gives you access to a huge number for pure-ruby modules (since they seem to have reimplemented most of the core classes).
The main drawback of JRuby is probably that the syntax is nothing like Java, but it may also be a strength: if you see it as a pure configuration language, it helps you keep your users in check (especially if they don't know Ruby, because they won't be able to link the config files they have in front of them with a real programming language, and therefore won't try to abuse it).
> The issue of Groovy is that the language is not quite > widespread, and not stable enough yet.
On the contrary, it hasn't changed at all for a while, as we're nearing the final release.
> Plus it doesn't put > enough emphasis on domain-specific languages, which are > very interesting for configuration files or behaviour > scripting.
Right, the stress is not put on DSL, but it doesn't mean you cannot write DSLs! On the contrary, the syntax is pretty flexible for that purpose. With closures, you can write custom control flow structures. With dynamic methods and properties on arbitrary classes, and operator overloading, you can easily write statments like account += 300.dollars. With our builders (that have been copied in Rails btw), you can easily create tree structured data. There are quite a few tricks under your sleeves to do pretty much any kind of DSL you like.
> It's only advantage is that it does quite look > like Java, but that's pretty much everything it has > running for it.
Come on! Is it some FUD you're throwing here? I suspect you haven't really used it to be able to say that it just has a Java-like syntax.
Groovy has at least partially messed up the syntax from Ruby that made this nice by changing object.method from a method call to a method *reference*, requiring () for method calls.
This makes the syntax of any DSL icky, and it breakes method and variable equivalence, which against breaks some very nice OO properties (anything can be refactored or simulated, and anything passed through by replacing the generic method handler - in Ruby, method_missing).
Guillaume, didn't we two discuss this a year or three ago, when you were first starting out with Groovy and I wrote in with feedback?