Welcome To The Nashorn Blog

Jim Laskey
Senior Development Manager

Welcome to all.  Time to break the ice and instantiate The Nashorn Blog.  I hope to contribute routinely, but we are very busy, at this point, preparing for the next development milestone and, of course, getting ready for open source. So, if there are long gaps between postings please forgive.

We're just coming back from JavaOne and are stoked by the positive response to all the Nashorn sessions. It was great for the team to have the front and centre slide from Georges Saab early in the keynote. It seems we have support coming from all directions.

Most of the session videos are posted. Check out the links.

Nashorn: Optimizing JavaScript and Dynamic Language Execution on the JVMUnfortunately, Marcus - the code generation juggernaut,  got saddled with the first session of the first day. Still, he had a decent turnout. The talk focused on issues relating to optimizations we did to get good performance from the JVM. Much yet to be done but looking good.

Nashorn: JavaScript on the JVM. This was the main talk about Nashorn. I delivered the little bit of this and a little bit of that session with an overview, a follow up on the open source announcement, a run through a few of the Nashorn features and some demos. The room was SRO, about 250±. High points: Sam Pullara, from Twitter, came forward to describe how painless it was to get Mustache.js up and running (20x over Rhino), and,  John Ceccarelli, from NetBeans came forward to describe how Nashorn has become an integral part of Netbeans. A healthy Q & A at the end was very encouraging.

Meet the Nashorn JavaScript Team. Michel, Attila, Marcus and myself hosted a Q & A. There was only a handful of people in the room (we assume it was because of a conflicting session ;-) .) Most of the questions centred around Node.jar, which leads me to believe, Nashorn + Node.jar is what has the most interest. Akhil, Mr. Node.jar, sitting in the audience, fielded the Node.jar questions.

Nashorn, Node, and Java Persistence. Doug Clarke, Akhil and myself, discussed the title topics, followed by a lengthy Q & A (security had to hustle us out.) 80 or so in the room. Lots of questions about Node.jar. It was great to see Doug's use of Nashorn + JPA. Nashorn in action, with such elegance and grace.

Putting the Metaobject Protocol to Work: Nashorn’s Java Bindings. Attila discussed how he applied Dynalink to Nashorn. Good turn out for this session as well. I have a feeling that once people discover and embrace this hidden gem, great things will happen for all languages running on the JVM.

Finally, there were quite a few JavaOne sessions that focused on non-Java languages and their impact on the JVM. I've always believed that one's tool belt should carry a variety of programming languages, not just for domain/task applicability, but also to enhance your thinking and approaches to problem solving.

For the most part, future blog entries will focus on 'how to' in Nashorn, but if you have any suggestions for topics you want discussed, please drop a line. 


Raging Red Rhino

Join the discussion

Comments ( 16 )
  • guest Thursday, October 11, 2012

    Really cool to see Oracle taking javascript to another level.

  • guest Thursday, October 11, 2012

    How Nashorn does relate to/build on top of Rhino at all? If it doesn't, then what are the differences? It will be great to have a real JVM implementation of JS. So, very interested to see where this project goes.

  • jlaskey Thursday, October 11, 2012

    Nashorn is a clean repo and uses no source from other JavaScript implementations, so there is no relationship to Rhino other than the ancestry of names. Nashorn is fairly strict with its adherence to ECMAScript-262 Edition 5.1, so there are a few backward compatibility issues against Rhino. Differences can be managed with a supplied Rhino compatibility script, loaded prior to running non-conforming scripts.

  • Michael van Niekerk Tuesday, October 16, 2012

    Yo dawg, I heard you like VMs, so I put a VM in your VM!

  • guest Sunday, October 21, 2012

    Really cool,

    will Nashorn provide full support for Continuation and similar features like saving execution context as is the case with Rhino ?

  • jlaskey Monday, October 22, 2012

    The current strategy for Nashorn is to follow the ECMAScript specification. When we release with JDK 8 we will be aligned with ECMAScript 262 Edition 5.1 (http://www.ecma-international.org/publications/standards/Ecma-262.htm). The follow up major release of Nashorn will align with ECMAScript 262 Edition 6 (http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts).

    Continuations are an experiment feature of Rhino (and only works in interpreter.) I can imagine that once Nashorn goes open source, experimental branches will be quite common.

  • kjin Wednesday, October 24, 2012

    To anyone reading this in the future:

    Nashorn will not be a drop in replacement for Rhino 1.7 because it does not support JavaScript 1.7 features and does not support continuations.

    However, this post does say that the next release of Nashorn will support ECMAScript Harmony, which is drafted to support features introduced in JS 1.7 such as "let", generators, iterators, array comprehensions, and destructuring.

    Nashorn may not support continuations, but developments on the Da Vinci Machine project in OpenJDK may allow Java developers to use continuations anywhere in a Java program (see http://ssw.jku.at/Research/Papers/Stadler11Master/ http://openjdk.java.net/projects/mlvm/subprojects.html#StackContinuations https://wikis.oracle.com/display/mlvm/StackContinuations).

    All in all, the future of scripting on the JVM looks bright.

  • Sean Gilligan Thursday, October 25, 2012

    What's the easiest way to get my hands on a copy of Nashorn? (I'm using Mac OS Mountain Lion if that makes a difference.)

  • jlaskey Friday, October 26, 2012

    You'll have to wait for the project to open source sometime this quarter.

  • Rick Bullotta Friday, October 26, 2012

    Is there a good summary of what is/isn't in the first release of Nashorn? It seems that not supporting iterators is a big omission, but perhaps I'm misunderstanding the description above. Also, I think it is very, very important that Nashorn natively support JSON and E4X - which are critical to enabling Javascript to be the full utilitarian scripting language for web apps that it could be. We leverage this extensively with Rhino, and the users of our platform love it, particularly E4X. Imagine trying to code up a bunch of Java XML API calls via Javascript - meh.

  • Sean Gilligan Friday, October 26, 2012

    I thought it might have been in the NetBeans beta. Can't wait to take it for a test drive...

  • jlaskey Saturday, October 27, 2012

    Experimental features like generators and E4X found in Rhino are not part of the ECMAScript Edition 5.1 specification, so will not be in Nashorn's first release. Our goal is provide features common in most implementations of JavaScript, like V8 and Nitro.

    That said, once Nashorn open sources, the community will likely introduce experimental features, into the project much the way they do for Rhino now.

  • Rick Bullotta Saturday, October 27, 2012

    Thanks for the feedback, James. My first thought was "just because the other kids are doing it, doesn't mean it's the right thing to do". ;-)

    Just to share a few thoughts: The ability to use an expressive syntax such as E4X to access XML documents is *extremely* powerful versus degrading to APIs that were/are optimized for Java code and non-dynamic scenarios. Our customers have been able to leverage this capability to effectively create server-side "script" handlers for almost every type of web API (REST, SOAP, etc.), without having to dive into code (and, most importantly, no compile/link/deploy/restart cycle).

    Just something to keep in mind. I'm sure Attila could port the Rhino stuff in a weekend, anyway. :)

  • kjin Saturday, October 27, 2012

    To jlaskey:

    It's not so much that they are experimental features, but are official features of JavaScript 1.7 (i.e., the Mozilla implementation). I believe the confusion lies in the commonly used name for JavaScript: the standard that all "JavaScript" engines follow is not the Mozilla one, but ECMA-262. I believe ECMAScript itself usually just reimplements features introduced in the newest versions of JavaScript. The next version of ECMAScript will implement features that are in JavaScript 1.7, for example.

    Since Rhino is a Mozilla project, it is very much expected that they would implement the latest spec of JavaScript rather than ECMAScript.

    It's a complicated relationship, but I wanted to clear that up for some people that may be confused.

  • daisuke Monday, October 29, 2012

    Great blog!!

    I have translated your article to Japanese.


  • Kaa Monday, August 8, 2016


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.