Easy external DSLs for Java applications

Or JRuby for fun and profit

I’ve been developing software for some time now, and have recently found myself applying ideas from various esoteric areas of computer-science to every day tasks of building common-place applications (often these concepts are quite old, indeed some were thought of in 1958).

One powerful idea that I’ve been playing with recently is that of embedding a DSL (domain specific language) into your basic application framework – and writing most of the features of the application in that DSL.

This is simply an implementation of the concept of raising the level of abstraction. The point, of course, being that when writing code in a DSL implemented in such a fashion, one can express ideas in terms of high-level abstractions that represent actual concepts from the problem domain. In other words, it is like using a programming language that has primitives rooted in the domain.

A lot of people have been writing about this kind of software design – and most implement these ideas in a dynamic language of their choice. How does one go about doing the same in a language like Java? That is what this article is about. And I cheat in my answer. Consider the following design stack -

Creating DSLs in JRuby

I propose that you only implement basic and absolutely required pieces of functionality in Java – the things that rely on, say, external systems that expose a Java interface, or some EJB-type resource, or some other reason that requires the use of Java. The functionality you develop here is then exposed through an interface to the layers above. You can also add APIs for other support services you might need.

The layer above is a bunch of JRuby code that behaves as a facade to the Java API underneath. This leaves you with a Ruby API to that underlying Java (and other whatever, really!) stuff – and makes it possible to code against that functionality in pure Ruby. The JRuby interpreter runs as part of the deployable and simply executes all that Ruby code transparently. As far as your Ruby code is concerned, it doesn’t even care that some of the calls are internally implemented in Java. Sweet!

We can stop here. At this point, we are in a position to write the rest of our application in a nice dynamic language like Ruby. For some people, a nice fluent interface in Ruby suffices – and keeps all developers happy. This is depicted on the top-left part of the diagram.

However, we can go one step further, and implement a DSL in Ruby that raises the level of abstraction even more – as referred to earlier. So on top of the Ruby layer, you’d implement a set of classes that allow you to write code in simple domain-like terms, which then get translated into a form executable by the Ruby interpreter. This is shown in the top right part of the diagram. Ultimately, potentially any one (developers, QA or business analysts) could express their intent in something that looked very much like English.

So where to write what?

How much to put in your Java layer depends on the situation – some people (like me) prefer to write as little as possible in such a static language. Others like the static typing and the associated tool support, and prefer to put more code here. When merely shooting for a little bit of dynamism through the DSL engine in the layers above, most of the code could be written in Java, and a fluent API in the dynamic language could be enough. When shooting for rapid feature turn-around and a lot more flexibility, most of the code could be in the DSL or in the external dynamic language.

The answer to this question really depends on things like the requirements, team structure, skill-sets, and other such situational factors.

OK, so where’s the code?

My intention with this post was to stay at a high level – and talk of how one could structure an application to make it possible to embed a scripting engine into it, and to give an overview of the possibilities this creates. In subsequent posts, I will talk about how actual DSLs can be created, tested, and also how a team might be structured around it.

Gotham Ruby Conference 2007

I attended GoRuCo 2007 yesterday, and it was a fine conference – where I met a bunch of old friends I hadn’t seen in a while. Here’s what the agenda looked like – I enjoyed the talks on Adhearsion, JRuby, and BNLs. And the conference took place in Google’s offices in NYC, and that was neat.

It was cool how many people knew of ThoughtWorks, and were interested in talking about what it was like to work there. (Probably less than the number that were interested in Google in the same way, but hey…) We ended the conference by finishing up with the afterparty in the wee hours of the morning. It was fun! Amazingly, both Deepthi and I won swag at the event – I got this neat laptop bag, and Deepthi got Rails Recipes. Oh, and here are some pictures.

You might want to read some live-blogging from the event.

The joys of large-screen monitors

In my ideal world, I’d have two 30″ Apple Cinema Displays, but my less than ideal world ain’t so bad either. My souped-up 24″ iMac serves me well for my day to day work, quite well indeed.

I’m positive that my productivity gains are large – I always have emacs open with at least 4 frames, or eclipse with several views open without anything important having to stay annoyingly minimized. I also have a browser open with lots of tabs, a bunch of terminals open with iTerm, and a bunch of other what-nots, and managing all this is easy. This multiple desktop manager makes it even easier. Finally, if all those windows distract you, use Think!

Anyway, if you want a quick and relatively cheap way (in the long run) to become more productive, get a large screen monitor. Or three.

From freedom languages to Java (and back again?)

Recently, I started working with Java again. I had little choice in the matter, really, since its for an upcoming product in the mobile application development tools space, and I’m focusing on the Java Micro Edition area. I’ll have more to say on this skunkworks initiative another time. (Watch this space, and all that).

I’ve been using mostly other languages in the recent past, Ruby, a little Python, Common Lisp, a little Haskell. But mostly Ruby. And it seems that having stayed Java-free for about two years has made me really rusty. That apart, this time around Java started out feeling annoying, and morphed into being mostly amusing. In an annoying way. The question I constantly have to tell myself to refrain from asking (out loud, and to the world in general) is – “Why can’t the bloody runtime figure this out for itself? Why do I have to type this extra (vestigial) code?”

In any case, working on the new Java Micro Edition platform again is nice – reminds me of a project I did at college – and of simpler times… :)