Building Domain-Specific Languages in JRuby

by Ian Roughley on May 21, 2007 |

Closing out the Java One conference last week was Rob Harrop's presentation "Exploiting JRuby: Building Domain-Specific Languages for the Java Virtual Machine." Domain specific languages (DSLs) have been gaining popularity, as shown on InfoQ with a presentation on an introduction to domain specific languages by Martin Fowler and posts on the debates in the blogsphere, and provide a way to create a custom language for a specific programming or business purpose.

But why would you want to do this? There are many possible answers, some of these are: repetitive tasks can be simplified; boiler-plate code can be encapsulated; or an API can be better express the intent of the code. No matter what your particular reason, all DSLs should deliver a clear value to your project.

The approach explored in the presentation was to create a JRuby DSL that is utilized from within Java classes. As byte code generated from JRuby will run in the JRE, the DSL is categorized as "internal" - which uses a general programming language to create a specific programming language. The alternative is an "external" DSL that requires an external compiler and generator, making the integration much more difficult.

The benefit in this approach is in creating the DSL, and several JRuby language techniques were presented to make developing DSLs easier:

Operator overloading - overloading operator allows the DSL to provide a natural syntax
Hashes and symbols - using hashes and symbols make it easy to express relationships and identify objects
Blocks - blocks encapsulate executable logic, and allow the logic to be stored (in hashes) for later execution
Dynamic type extension - methods can be added dynamically to classes and objects
Method missing - when a method is called that doesn't exists it can be trapped, avoiding the need to know all the operations in advance
Integration - take advantage to existing Java code

To take full advantage of using JRuby in creating the DSL, tips on style were provided:

Ensure that you are not writing Java code in a dynamic language
Build up the DSL from common building blocks
Identify the problem and then create a syntax to express the solution
Provide metadata and behavior - don't let DSLs become configuration files
Think the ruby way: use type extensions; use blocks; use methods on objects
Keep the scope limited; address a small part of your domain and don't try to make the DSL a general programming language

For developers, DSLs are another tool that can be utilized. By investing a little time upfront, large time savings can be achieved.

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

eBook: The New Kingmakers - How Developers Conquered the World

Building Content-Driven Apps - Couchbase and Elasticsearch for Content and Metadata Stores

Faster PHP Through Java

Infographic: Just How Big is the Nerd Economy

Related Sponsor

Get code level visibility into your web apps. All for free.

Try New Relic Today.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Groovy, an other option by Guillaume Laforge Posted

Groovy, an other option by Guillaume Laforge

Additionally, there's the option to use Groovy for embedding DSLs in your Java EE application. There's a short page on the Groovy site with a couple pointers to how to create Domain-Specific language in Groovy -- especially the tutorial from QCon 2007 which provides some explanations on the various tricks that Groovy offers.