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.

Applets aren’t always evil

Applets are hated by users and developers alike. The infamous grey box combined with slow startup times caused them to disappear almost completely from most web developers’ toolboxes. They are now widely regarded as a failed and overhyped attempt to deliver a desktop-like user experience in browsers, eclipsed by more lightweight alternatives such as Flash or Ajax. However the Java runtime and browser plugins are already installed on most computers (our logs indicate 98% of our visitors) and the Java platform continues to thrive.

For the implementation of the visualiser in the SONAR platform (also included in the Enron Explorer), an interactive visualisation of complex social networks graphs [1], our first instinct was to consider alternatives to Java. After a bit of investigation we found that both Flash and DHTML were far too slow and would require a significant amount of bespoke work… So we turned our attention back to Java. Our earlier successful development of Metascope, a Java Web Start/desktop application based on the excellent Prefuse visualisation toolkit, tempted us to reconsider the applet route. Code reuse is a Good Thing after all.

After implementing a first prototype we came to the conclusion that applets and Ajax/JS are actually a good match, allowing many of the applets’ shortcomings to be worked around quite easily.

Making applets optional

We decided to make the applet completely optional - it is inserted with Javascript only after the user has ‘opted in’. This avoids the browser lock-up during the first page load, one of the reasons for the unpopularity of applets, and bypasses the large download for those who cannot or do not want to use it.

Adding Ajax

Unfortunately applets, still stuck in web prehistory, don’t integrate as seamlessly as other plugins with web pages. As soon as the user navigates away from the page containing the applet, the browser unloads the virtual machine, causing another delay as the page gets loaded again. HTML frames are commonly used to work around this issue, a big no-no in modern web design.

This is where Ajax comes to the rescue. Ajax and other techniques, like Lightboxing, have made the construction of complex single-page web applications very simple - so the applet can remain loaded while portions of the page are updated without refreshing the whole page. This gets around the long delays that the user would have to sit through with repeated loading and unloading of the Java virtual machine.

LiveConnect: Interaction with the browser

Applets are not usually self contained and need to interact in some way with their host environment. This is accomplished with LiveConnect, a Java-Javascript bridge which was first introduced in 1996 with Netscape 3.0 but never got much attention. The API is surprisingly simple to use and methods on the applet can be directly invoked from Javascript:

// “applet” is the id of the applet
document.applet.itemClicked(id);

The fact that modern web applications use Javascript libraries such as Dojo or Prototype makes integration very simple: they almost always provide callbacks which can be used to notify the applet of changes made to the page:

// example with Prototype:
// invoke method after successful ajax request
new Ajax.Request(url, {
…,
onSuccess: function(req, obj) {
document.applet.success(req.status);
}
});

On the applet side, partial page reloads (as a result of user interaction) are triggered by evaluating Javascript directly:

// “this” is referring to the applet object
public void itemClicked(int id) {
JSObject.getWindow(this).eval(“focusItemId(” + id
+ “);”);
}

In this example focusItemId is a custom Javascript function, included using normal <script> tags. It will typically issue an asynchronous request to update parts of the interface. Although LiveConnect is not widely used the implementation seems to work quite well with recent browsers and versions of Java. The class files needed during the development of the applet are contained in plugin.jar which can be found in the jre/lib subdirectory of the JDK.

Conclusion

In situations where Java is a good tool for the job (CPU and graphicly intensive client applications), a combination of Ajax, LiveConnect and simple Javascript can greatly reduce the pain usually associated with applets.

Looking to the future, Sun has finally realised that the Java Plugin implementation needs reworking. There is now a proposal for a minimal Java runtime environment named “Java Kernel”, which could be used to make the Java plugin indistinguishable from other plugins in terms of loading times.

Although Sun has already lost a lot of its credibility in the web development community this could be their chance to redeem themselves.

Notes

[1] Flash, the obvious choice, seems to get used quite a lot recently to build web-based infoviz solutions, but most of them tend to be custom built with little code reuse. Performance is another known issue with Flash.

Pure Javascript solutions like JSViz are interesting but currently too slow for visualisations of big datasets (as discussed recently on Ajaxian).

The best solution would probably be a mix of JS and Java, combinbing Java’s performance and powerful apis with an easy to use Javascript programming model.

Update: 20/11/06

Chet Haase at Sun suggests the name Applet-JAX: his blog post mentions the possibilities of mixing applets and other media in order to get away from Java-only solutions. However, the demo he provides does not make use of asynchronous updates.

Update: 28/11/06

My colleague Mike came up with “AppleJax”: a lot easier to use in conversations. Names are important!