(take 6 jim-crossley)

Posted by on Jun 01, 2012

Jim Crossley and his team at Red Hat are attempting to create the programming language polyglot's dream. Their latest creation Immutant is billed as a Clojure application server built on JBoss, but as you'll discover below is aiming to integrate numerous Java.next languages. Immutant is an exciting project and looks destined to become something special.

What is the "elevator pitch" for Immutant?

Immutant is an application server for Clojure built atop JBoss AS7.

Our primary goal is a robust, scalable deployment platform for Clojure applications, with built-in services like messaging, caching, distributed transactions and clustering. We aim to encapsulate the accidental complexity associated with most non-trivial applications and allow the developer to focus on the essential complexity of his problem domain.

Immutant is an integrated stack of services. Instead of provisioning your servers with Jetty for web, RabbitMQ for messaging, and Memcached for caching, for example, you could simply install Immutant.

We currently have projects to support JRuby (TorqueBox) and Clojure (Immutant) apps, and we're looking at exposing the AS7 services to Scala, Python, and JavaScript as well. All of these projects can be overlaid on each other, creating an app server that provides services for multiple languages at once. This allows you to leverage the libraries and skills appropriate to any particular aspect of your application, regardless of the language, e.g. Rails used in the front-end web tier and perhaps Incanter used for back-end report generation.

Were there any barriers to using Clojure in the implementation of Immutant?

Quite the contrary, Clojure has enabled us to remove much of the boilerplate typically associated with JEE services, so we've been able to encapsulate the complex JEE API's and configuration within a small set of Clojure functions.

Clojure also inspired us to support more dynamic applications. It's not necessary to declare all the services required by your app in some sort of "deployment descriptor" for Immutant; those decisions can be deferred until runtime. We also let you expose the application running within Immutant via either Swank or nREPL, enabling a more interactive development experience than what folks typically expect from a JEE container.

So far, the biggest challenge has been working around Clojure's assumption that there is only one Clojure runtime per JVM - we wanted each application deployed within an Immutant to have its own runtime, and even its own Clojure version. To work around this, each application gets its own isolated ClassLoader and we do some classloader munging to give each application its own runtime.

We're aided in this by JBoss AS7's modular classloading system - it does a great job of isolating an application's dependencies from those of other applications or Immutant itself.

Why do you think that there are some who are mistrustful of "Clojure in the enterprise"?

Answering this question requires making broad assumptions about the fears and motivations of others, not to mention an agreed-upon definition of a pretty overloaded term... but what the hell! :)

Fear is the mind-killer.

Seriously, I don't think good developers are mistrustful of Clojure, though some may be justifiably leery of bloated application servers that are traditionally associated with enterprises. JBoss AS7 is not your father's app server: though obviously bigger than any single component of a home-grown stack, it's fast and light enough to not make you "stabby" while coding on your laptop.

But developers are usually only one minority amongst the decision-making stakeholders in an enterprise...

How can Immutant alleviate those doubts?

Oddly, the integrated, java-app-server-ness aspect of Immutant that gives some developers pause is the very thing that IT managers and sys-admins love. Immutant offers a great opportunity to "get Clojure in the enterprise" because it can deploy those Java legacy apps right alongside the newer Clojure/JRuby/etc ones, with minimal impact to the devops guys.

But truthfully, we don't really care about that. We're looking for ways to make development and deployment simple. And by simple, I mean no more complicated than what's required to address the problems within a specific domain.

And though it's true that forces acting on an enterprise often complect applications in ways that don't affect individuals or small teams, we think simpler development and deployment benefits everyone, whether you develop apps for/in an enterprise or not.

What is the state of Clojure in the broader Red Hat corporation?

Well, when we started Immutant almost a year ago, it was pretty much just me and Toby. ;)

We're part of a research team at Red Hat led by our "Director of Polyglot"[1], Bob McWhirter. We're fortunate to have recently added Charlie Nutter and Tom Enebo (the JRuby guys) to our team, and both are very interested in alternative JVM languages (including Clojure) and eager to apply their skills to our JVM-related projects, including TorqueBox, Immutant and OpenJDK, among others.

Red Hat is a very large company of very smart engineers on very long leashes, so I have little doubt others are using Clojure internally. And we have a solid mandate from our leadership to expose the excellent JBoss services through as many JVM-based languages as makes sense.

Do you think that there is a synergy between JRuby and Clojure in the enterprise?

Absolutely! And not just in the enterprise. The proliferation of web frameworks and tools for Ruby make it a great language for developing web UI's and/or services, whereas to this point Clojure has mostly been used to create some pretty incredible data analytics applications.

It's rare to find individual developers with enough expertise in both JRuby and Clojure to effectively combine frameworks and libraries from each. But we believe they're out there, and as the benefits of polyglot programming become more publicized, their numbers will increase. But in the meantime, we expect larger organizations to form teams of experts from both camps, each producing loosely-coupled applications that coordinate to solve domain-specific problems.

We hope Immutant will appeal to both individuals and teams by allowing those seemingly disparate applications to be easily developed and deployed to a single platform.

[1] Best job title ever!

blog comments powered by Disqus