Wednesday, April 22, 2009

The Future: Part One

There's been a lot of supposition about the future lately, and I've certainly read and succumbed to the temptation of the prognosticator. I'm not going to comment on any of the players or put forward my own suppositions about what might happen. What I will do here is talk about what *should* happen.

It's apparent that the Java platform is at a crossroads. One path leads to irrelevance, be it through general apathy that important technologies are getting sidelined, or through active emigration due to bureaucratic processes and waterfall platform evolution. The other path leads to a bright, open future, where polyglots romp and play with fresh new languages and developers have freedom to use whatever tools they feel are necessary for a given job. Given the large investment many of us have in this platform, we need to start talking now about which direction we want to go.

I've been doing a lot of thinking about the future of the Java platform and my future developing for it, and I've come up with a few things I believe must happen soon to ensure the future of the JVM and the applications and languages built for it.


As you might expect from me, the first area involves supporting many languages on the JVM. Over the past three years we've seen a spectacular transformation take place. The "Java" VM has become a truly multi-language platform. People are putting into production applications running all sorts of languages, often writing absolutely no Java to do so. And this is how things must be...this is how the platform is going to survive.

As I see it there are currently three primary players in the language domain: JRuby, Scala, and Groovy (in no particular order). I include these three due to the relative completeness of their implementations, vague popularity metrics, and availability of production use cases. These three languages, one static and two dynamic, bear further exploration.

JRuby represents the promise of off-platform languages being brought to the JVM. Rather than creating a language specifically tailored to fit well into the JVM's type system and limitations, we have managed to take a drastically different language and implement enough of it to be the only "alternative" implementation realistically considered for production applications. And in doing so we've had to stretch the platform. We've created native binding libraries, wired in POSIX functions the JDK doesn't provide, implemented our own core types like Strings, Arrays, and regular expressions, and done all this while managing to deliver the best performing compatible Ruby implementation available. And where the other two primary language contenders largely pull developers from other areas of the Java platform, JRuby actually brings in many developers that might not otherwise ever use the JVM. JRuby stretches and grows the platform.

Groovy is the second dynamic language under consideration. Groovy represents taking the best features of a number of dynamic languages and wiring them into a Java-like syntax that's easy for existing Java developers to learn. Groovy provides a solid dynamic language foundation without breaking Java type-system requirements like ahead-of-time compiled classes and static method signatures, allowing it to enlist directly in newer APIs that depend on those requirements. And while many developers come to Groovy from other areas of the Java platform, they might also have completely left the platform if not for Groovy. Groovy provides for Java developers a "dynamic layer" that doesn't require them to learn a new platform and a new set of libraries. And so Groovy's strength is in maintaining the platform and stemming the bleeding of developers to off-platform dynamic languages.

Scala, it must be stated, is the current heir apparent to the Java throne. No other language on the JVM seems as capable of being a "replacement for Java" as Scala, and the momentum behind Scala is now unquestionable. While Scala is not a dynamic language, it has many of the characteristics of popular dynamic languages, through its rich and flexible type system, its sparse and clean syntax, and its marriage of functional and object paradigms. The supposed weakness of Scala as being "too complicated" or "too rich" can be countered by developing coding standards, creating more robust editors and tools, and by better educating polyglots on how best to use Scala. Scala represents the rebirth of static-typed languages on the JVM, and like JRuby it has also begun to stretch the capabilities of the platform in ways Java never could.

Among the secondary players I include language implementations like Jython, Clojure, and Rhino. While still in early days of adoption (or in Jython and Rhino's cases, early days of re-awakening), they represent similar aspects to the primary three languages. For purposes of discussion, we'll leave it at that for now.

In order for the platform to embrace these and many future languages, several things need to happen:
  • Ongoing work on these languages must be funded in such a way as to avoid product lock-in. Funding them by tying them to specific technologies will only fracture development communities, and likely damage any existing open-source contributor base.
  • There must be paid support offerings for these languages outside of specific products. For people interested in running JRuby on Rails, Grails, or Liftweb, there must be support channels they can follow, regardless of product bundling attempts. In the JRuby world, for example, we receive many requests for paid support, either in the form of hired guns to optimize an application or through targeting resources to critical bugs. And so far, we have been unable to offer such support.
  • We must continue the work started on the OpenJDK and MLVM projects. OpenJDK has enabled such projects as Shark (Hotspot on LLVM) and the MLVM (JVM extensions for non-Java language features), and we must see these efforts through to completion.
  • Finally, we need a "languages czar" that can coordinate the technical aspects of these various projects and help direct resources where needed. This would largely be a community-cultivating role, but as a sort of "open-source manager" to ensure development efforts are both cooperating and not being needlessly duplicated.
I believe it's absolutely vital that these tasks be met, or we risk the future of the platform entirely. And losing must not be an option, lest we fall back into proprietary alternatives controlled by a single entity.

More to come.


  1. good review of the actual situation and trends of JVM although i am a clojure fan and would it on top of the JVM realm :-P

  2. Great post. I for one, play in the static languages league and would love to see something like Scala taking the baton from Java (especially since the evolution of Java hits brick walls like we see once again in Java 7 - no hope for closures, reified generics, properties etc.) I've been learning JavaFX even not being a GUI guy, just for the sheer pleasure of using a languge that keeps what I love from Java but adds type inference and other modern traits like some support for FP. And I echo your words on Scala's complexity - the language is already a little hard for less experienced developers, I hope they don't go the way of Haskell which was a hugely promising language but became a playground of PhDs in post-modern typesystems and completely died as a viable mainstream language (wonder if Haskell' has any chance to revert that).

    I hope Oracle understand the enormous value of what you and other alternative-JVM-languages hackers have been doing. Ditto for other major players, IBM for example seems to be supporting Groovy as one of their "sMash" languages; Google is also being very helpful to make several languages work in their AppEngine for Java.

  3. I guess I commented too fast. You did mention clojure. Lots of people like Clojure, including myself (just as much as I like JRuby) and there's lots going on in the community.

  4. I enjoyed reading this, thanks for posting. Looking forward to more posts on the future of the JVM.

  5. @Charles - I'm very curious about the czar thing. Even relatively homogenous projects with a well recognized leader like the Linux kernel project are just shy of rampant anarchy. How can a language czar have any real influence across multiple communities with different goals?

  6. Will the Language Czar have to face scrutiny regarding whether or not they paid their taxes? If so, there's, unfortunately, little hope in the position being filled.

  7. Well anonymous, that article was from 2007 and the JVM has changed in the meantime. I believe the author of this blog is the main force behind that effort.

  8. Great post. I find it very amusing, though, that you neglected to mention JavaFX. That's my experience, too, but Sun obviously wouldn't agree, judging by the topics at the upcoming JavaOne conference. :)

  9. James, I don't think JSR 192 is finished yet, and invokedynamic isn't available in any JVMs is it? Actually, I was comparing it to the Strongtalk vm, what a shame that Sun didn't choose to finish it instead of having its authors work on Java.

  10. You've neatly summed up my thoughts about the future of Java. I've used (a little) Groovy, but I really miss the refactoring and code-completion comfort that only static types can give.

    Scala apparently has managed the unite the best of both type systems (dynamic and static types) and programming paradigms (OO and functional).