Welcome To The Nashorn Blog

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


Really cool to see Oracle taking javascript to another level.

Posted by guest on October 11, 2012 at 06:14 AM PDT #

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.

Posted by guest on October 11, 2012 at 11:40 AM PDT #

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.

Posted by jlaskey on October 11, 2012 at 12:12 PM PDT #

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

Posted by Michael van Niekerk on October 16, 2012 at 06:44 AM PDT #

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

Posted by guest on October 21, 2012 at 12:36 PM PDT #

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.

Posted by jlaskey on October 22, 2012 at 06:32 AM PDT #

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.

Posted by kjin on October 24, 2012 at 04:48 AM PDT #

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.)

Posted by Sean Gilligan on October 25, 2012 at 03:51 PM PDT #

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

Posted by jlaskey on October 26, 2012 at 04:32 AM PDT #

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.

Posted by Rick Bullotta on October 26, 2012 at 11:29 AM PDT #

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

Posted by Sean Gilligan on October 26, 2012 at 11:38 AM PDT #

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.

Posted by jlaskey on October 27, 2012 at 06:51 AM PDT #

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. :)

Posted by Rick Bullotta on October 27, 2012 at 06:56 AM PDT #

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.

Posted by kjin on October 27, 2012 at 06:58 AM PDT #

Great blog!!
I have translated your article to Japanese.


Posted by daisuke on October 28, 2012 at 11:19 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Technical discussions and status of the Nashorn JavaScript Project.


« July 2016