This post is geared towards web developers coming from Ruby on Rails, Node.js or both. As a web developer with former experiences with Java and JEE, currently engaged with Rails during days and Node at nights, I want to share my perspective on an interesting recent peace of news with you.

You may know therubyracer gem for executing JavaScript sources in Ruby. As I was fooling around with ExecJS lately. Every person who has written CoffeeScript before, e.g. within Rails, has already used this overwhelmingly useful piece of software. The recent news of a new JavaScript engine called Nashorn entering the realm of FOSS did not create buzz on everybody’s dearest news site. That’s really a pity, and as you may have guessed, we’ll see why in this post.

Horned Homology

Project Nashorn is a greenfield implementation of ECMAScript-262-5, started in 2011 by Oracle. It replaces Rhino in OpenJDK 8, and is thus scheduled to ship publicly in 2013. The main rationale behind Nashorn is benefiting from JSR-292: Dynamic Languages on the JVM aka InvokeDynamic. Nashorn has some lifetime already: It used to be closed source but was recently released into the wild (heh). The source has been donated to the OpenJDK.

Several reasons speak for retiring Rhino, the main one being a huge effort of using invokedynamic properly. Rhino is old and slow: Its development started in 1997 (11 years ago!) at Netscape, even before the age of the now-standard HotSpot JIT compiler. Thus, it relies on interpretation - unlike V8, whose speed benefits mainly rely on just-in-time compilation of JS to machine code, which it does pretty memory-hungry. Nashorn, however, is said to be quick already - Node with its V8 is still the performance champion, but Nashorn races to challenge the throne.

These circumstances cry for a fresh overhaul - good to hear that Nashorn aims to be fully backwards compatible.


Here comes the hot part: With Nashorn also comes Node.jar, a Nashorn-based implementation of Node’s evented API. Currently based on Node v0.8.2, Node.jar is tested against the Node test suite for full compliance.

Node.jar a mapping Node’s API to Java-native pendants, nothing more and nothing less. This is quite feasible, as displayed by e.g. the often-cited file system example: Java’s nio packages, which weren’t too common in plain old Java development, have been providing async file system access for some time now. With JSR-203, they have received an overhaul in Java 7, namely NIO.2.

Unlike Nashorn, Node.jar has been hardly covered and seems to be in its infancies. I’d assume that a npm pendant is crucial for Node.jar’s success, but there are no news on that yet. But the promises are well enough for us to keep a close eye on it.

Runtime redundancy for the good

But why another Node, you may ask?

In my opinion, competition fosters and drives innovation. See the close example of in-browser JavaScript runtimes: With Google entering the stage, the war on challenging A second implementation of Node will further drive its standardization and adoption

The biggest benefits stem from running on the JVM. This enables the deployment on already available Java-based infrastructure. Especially on Windows, the pains that Node faces with its platform implementation, can be laid off to the JVM. Using Java application servers, especially JBoss, for deploying Node apps (or Ruby apps with embedded JS!) sounds promising. Their purpose is to provide common services to user apps which are ready to be reused. While Ruby did go the extra loops of reinventing database access, messaging, caching, replication, and Node has this obstacle still in front of it. For Ruby, the Torquebox project demonstrated how often sneered at giants like JBoss can be used for good, even for modern, dynamic web apps.

Finally, there is the “door opener” aspect. Grassroot-like enterprise adoption by sneaking into the existing Java-based infrastructures was and is a main rationale behind JRuby. Also, the JVM currently moves towards embedded, as efforts of an modular and small core JRE show. Having conquered the server already, embedded becomes the next area that JS developers can settle into. For example, how would the Nodecopter people like a native Node.js on a Raspberry Pi?

Java + JavaScript = JavaJavaScript ?

(Fun fact: Nashorn’s command line runner is in fact named jjs)

Okay, but what’s in for Ruby developers? There’s ExecJS to integrate my runtime from Ruby, be it Node, V8, Rhino or Nashorn.

With Node.jar and JRuby, there are implementations for both JavaScript and Ruby running on the JVM. In an ideal state, application parts written in JavaScript could be called from parts written in Ruby without process boundaries, since both run on the same JVM instance. This same-process interop is basically beneficial to all scenarios that involve ExecJS. Consequently, the need for wrappers and shelling out disappears, in theory providing a speed up.

Another aspect of Ruby and JavaScript playing nicely together on the JVM playground: Up to now, certain use cases require both runtimes, Ruby and JS. Distribution barriers for applications that apply to this scenario are significantly lowered if the JVM is the only runtime and environment dependency. Even better that it has a high penetration among server environments already.

What could possibly go wrong?

As always, there are caveats. Since Node’s strengths lie in the asynchronous, I see the main area of conflict in the re-use of common but synchronous Java APIs - e.g. JPA, JEE’s prominent database abstraction.

If you are as fascinated about this topic as I am, be warned: This is explorative territory. Keep an eye on the OpenJDK 8 project page. Save the date for the developer preview on end of February and mark your calendars for Q3/2013, when it is due for General Availability. And despite Nashorn being available rather soon, it should take some time for Node.jar to reach production readiness.


If you want to give Nashorn a spin, grab a JDK8 and check out the source. The README points to everything you need to get going. Also check out the blog post ‘Open for business’. I went with a precompiled JDK8 build and just the Nashorn source (requires Mercurial), since that was too easy.

hg clone nashorn
cd nashorn
(cd make ; JAVA_HOME=/path/to/jdk8 ant)

Spin up the Nashorn console from the Nashorn directory:

JAVA_HOME=/path/to/jdk8 sh bin/jjs

Happy hacking!

Some additional Linkspam:

blog comments powered by Disqus