Java JVM at 20

The JVM, Java’s other big legacy

Think of Java, which celebrates its 20th anniversary this week, and your first thoughts most likely go to the language itself. But underneath the language is a piece of technology that has a legacy at least as important and powerful as Java itself: the Java virtual machine, or JVM.

Because the JVM wasn’t designed to run any particular language — Java is only one of many possibilities — it’s become somewhat of a platform unto itself. Languages have been developed for the JVM that owe little or nothing to Java, and the future development of the JVM is turning more to empower the creation of new items that can leverage Java’s existing culture of libraries and software or depart from it entirely.

The engines under the JVM hood

When people talk about the JVM, they’re generally referring to a specific JVM: the one originally produced by Sun Microsystems and now owned by Oracle, which uses the HotSpot engine for just-in-time compilation and performance acceleration. With proper warmup time for long-running applications, code operating on HotSpot can sometimes meet or beat the performance of code written in C/C++.

Nothing says the HotSpot-empowered JVM has to be the one and only implementation of Java, but its performance and many years of development have made it the de facto choice for good reason. A galaxy of other JVMs have come (and gone), but HotSpot itself — now an open source project — remains the most common option for enterprise production use.

Here and there, though, others are attempting to become the keepers of their own JVM flame: One programmer, for instance, is developing a JVM entirely in Google’s Go language — although right now more as an experiment than as a serious way to give HotSpot any kind of competition.

Because of all the advanced optimization work put into HotSpot, the JVM has over time become a target platform by itself for other languages. Some are entirely new creations designed to exploit the JVM’s high speed and cross-platform deployment; others are ports of existing language. Plus, using the JVM means devoting less work to creating a runtime for a language from scratch.

The big JVM stars: Clojure, Scala, and Groovy

Of the languages created a new on the JVM, one stands out for being most unlike Java as possible: Clojure, a functional language designed (in the words of its creator, Rich Hickey) to be a “kind of a Lisp for the JVM,” one “useful anywhere Java is.” Or even where Java isn’t: Puppet Server, for example, recently swapped out Ruby for Clojure as its core language, citing performance as one reason for the switch.

Aside from its power as a functional language, Clojure illustrates one of the fringe benefits of creating a language for the JVM: access to all of the resources provided by Java itself, typically libraries like Swing or JavaFX. To that end, developers more comfortable with Clojure can write programs sporting platform-native UIs, by way of what Java already offers — but without having to write Java code directly.

Scala, another functional language for the JVM, hews more closely to Java in terms of syntax, but it was created in response to many perceived limitations of Java. Some limitations, like the lack of lambda expressions, have been addressed in recent versions of Java. However, Scala’s creators believe such improvements will leave developers wanting even more — and Scala, not Java, will provide them in ways that developers will prefer.

Groovy, formerly stewarded by Pivotal but now an Apache Software Foundation project, was also developed as a complement to Java — a way to mix in features from languages like Ruby or Python while still keeping the resulting language accessible to Java developers. It, too, functioned in part as a critique of Java by providing less-verbose versions of many Java expressions.

The JVM ports: Jython, JRuby, and the rest

Another side effect of the JVM serving as a language target: Implementations of several languages now run there as well. For example, if you thought Node.js was the first time JavaScript ran as a server-side entity, think again: Mozilla’s Rhino has been doing so, in Java and on the JVM, since 1999 (albeit in only an open source variety after 2006).

Most prominent among the ported languages — and relevant to enterprise developers — are Python and Ruby, which have been implemented in JVMs as Jython and JRuby, respectively. As with the other JVM languages, hosting Python and Ruby on the JVM gives them access to the existing universe of Java software. This relationship works both ways: You can leverage Python from within Java applications as a scripting language for testing, by way of Jython.

Despite the speed of languages on the JVM, there’s no guarantee that a JVM-ported version of a language will be higher-performing than its other incarnations. Jython, for example, is sometimes faster, sometimes slower than the conventional CPython implementation; performance depends greatly on the workload. Likewise, JRuby can be faster than its stock implementation, but not always.

Another disadvantage of a JVM-hosted version of a language: It doesn’t always track the most recent version of the language. Jython, for example, supports only the 2.x branch of Python.

The next steps for the JVM

Even apart from performance issues, it’s unlikely any of these languages will replace Java. But that has never been the plan — after all, why replace Java when it’s so widely entrenched, successful, and useful?

Instead, it’s better to take the culture that’s sprung up around Java — all the libraries and applications — and make it useful by way of the JVM to far more than Java programmers.

Next, the JVM must become easier to use as a development environment for forward-thinking language work. In 2014, Oracle unveiled Graal VM, a project that exposes the JVM’s innards via Java APIs. When completed, this will allow programmers to create new languages for the JVM by using Java as a kind of command-and-control language. (Prototypes of JavaScript, Ruby, and R hosted with Graal showed promising, if inconsistent, results.)

Tougher to predict is whether the JVM or its successors can foster a new language that’s as influential and broad as Java itself — or whether such a language comes from another direction entirely.

JavaScript and the V8 engine for JavaScript are strong candidates as influential successors to Java. Node.js already has a culture of software reuse akin to Java’s own, and languages that transpile to JavaScript allow use of the ecosystem without having to write JavaScript.

But with Java preparing for major makeovers, languages on the JVM seems far closer to the beginning of their journey than to the journey’s end.