Why Rails and Node.js Folks should care about Project Nashorn
At least if taking my opinion as fact
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.
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?
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?
(Fun fact: Nashorn’s command line runner is in fact named
Okay, but what’s in for Ruby developers? There’s ExecJS to integrate my runtime from Ruby, be it Node, V8, Rhino or Nashorn.
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 http://hg.openjdk.java.net/nashorn/jdk8/nashorn 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
Some additional Linkspam:
- Java Spotlight Episode 92: Jim Laskey on Project Nashorn. A recent episode of the Java Spotlight potcast has a feature interview on Nashorn and the open sourcing that was the move into OpenJDK.
- Project Nashorn Slides & Talks. Dalibor Topic has a a collection of slides and talks on Nashorn internals. Care if you want to dig deeper.
- Nashorn, Node.jar and Java Persistence BOF (Session minutes)
- The Nashorn blog on Oracle Blogs
blog comments powered by Disqus