The term “XML sit-ups” is often used by Rails developers to make fun of the XML-loving Java crowd. When I first heard it, I was slightly annoyed - there’re many valid use cases for XML. However, using it as a scripting language is clearly not one of them. The build system Ant fell into this trap, and so did the Spring Framework: the configuration is just too verbose and awkward.

<bean id="bean3" class="springy.beans.Bean3">
<constructor-arg value="${vic}"/>
<constructor-arg ref="bean2"/>
<property name="aProperty">
<list>
<ref bean="bean1"/>
<value>A String</value>
</list>
</property>
</bean>

This slightly contrived example creates a new instance of the class springy.beans.Bean3 (passing two values to the constructor) and eventually sets a property (in this case of type java.util.List) on the instance. The first constructor argument, ${vic}, is a placeholder which will get resolved at runtime (requiring more plumbing, I’ll spare you the details).

Fortunately, the bean/object management bits of Spring are completely unaware of the XML horrors happening around them, in best Java tradition (“if we need to change the implementation some day”). I decided that the day had arrived, inspired by a blog post talking about a successful Groovy-based Spring configuration (Programmatic Configuration in Spring).

Instead of Groovy I opted for Ruby (in its Java-based incarnation JRuby), a language known for its DSL-friendly syntax. Trying to make the DSL similar to Rake’s the above XML turned into:

bean :bean3, “springy.beans.Bean3″ do |b|
b.new(vic, :bean2)
b.aProperty = [ :bean1, “A String” ]
end

A fair bit of Ruby’s magic is used to make this possible: the notorious method_missing to set properties and :symbols to reference existing beans. The nice thing about using a DSL based on real programming language instead of pure XML is that you can use all features the host language has to offer. For example, constructs like <import resource=”x”/> can be replaced with Ruby’s require() or load() mechanisms. This is not only restricted to Ruby code, as JRuby allows you to use normal Java objects as well.

Extending the syntax is just a matter of adding methods, as opposed to having to deal with XML schema and coding definition parsers. The Extensible XML authoring example from the Spring documentation translates into the following Ruby code:

def dateformat(id, format, lenient=false, args = {})
register_bean(BeanDef.new(id, “java.text.SimpleDateFormat”, args)
.new(format).lenient(lenient))
end

This is three lines of code compared to writing the XML schema (20 lines), parsing handler (30 lines), namespace handler (10 lines) plus registering the handler and schema (two configuration files to edit).

In case that XML really is required, you can put additional XML markup inline:

inline_xml do <<XML
<beans>
<bean id="bean1-2" class="springy.beans.Bean1"/>
</beans>
XML
end

The implementation of this DSL requires ca. 200 lines of JRuby and 20 lines of Java. However, the obvious advantage is not the DSL itself but the access to both Ruby and Java from within the ‘configuration’ files, giving way to far more interesting possibilities like Ruby-based AOP (currently not implemented), which could look like this:

around_advice “expression(* foo(..))” do |joinpoint|
joinpoint.this.do_something
joinpoint.proceed
end

In case you want to give it a spin you can find the code here. However, bear in mind that it is far from being complete as many features are currently not implemented. It serves more as a proof of concept and starting point for a full implementation. Also, using an interpreted language there’s an obvious performance overhead but it’s not that noticeable (ca. 1 sec slower on my machine) and the increased flexibility makes more than up for it. Things can only get better: the JRuby guys are putting a lot of effort into performance improvements at the moment.

Edit 08/12/06: Simplified example

Edit 18/12/06: Got some interesting feedback from the InfoQ community. The readability of the DSL was a main concern of most of the posts. I must admit that it is probably difficult to read without some basic understanding of Ruby concepts and data types. It is probably more interesting to developers already familiar with Ruby. It’s a typical problem with internal DSLs.

This entry was posted on Tuesday, November 21st, 2006 at 8:25 am and is filed under Java, Ruby. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.