Nashorn is a JavaScript runtime based on the InvokeDynamic instruction and series of APIs added to the Java VM in Java 7. These APIs are set to be radically improved in Java 8, compiling the existing JVM instruction to bytecode which will pass through the full HotSpot compiler.<p>If you're interested in InvokeDynamic, perhaps you'll check out the slides on a talk I gave about it:<p><a href="https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to-hotspot" rel="nofollow">https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to...</a>
At JavaOne this year, the Nashorn team were also demoing Node.jar, a port of the Node.js APIs which runs on Nashorn.<p>The talk one of the team members gave [1] on invokeDynamic and their under-the-hood Dynalink [2] library was pretty interesting.<p>Links to all the Nashorn sessions at JavaOne are available on their blog [3].<p>[1]
<a href="https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=5251" rel="nofollow">https://oracleus.activeevents.com/connect/sessionDetail.ww?S...</a><p>[2] <a href="http://szegedi.github.com/dynalink/" rel="nofollow">http://szegedi.github.com/dynalink/</a><p>[3] <a href="https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashorn_blog" rel="nofollow">https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashor...</a>
Rhino has pretty good performance. It's about 1.6x Java's performance which made it pretty darn fast for most scripting languages built on the JVM. I would expect this new project will follow the ScriptEngine API so you could swap out a Rhino interpreter with Nasborn engine. This would make it easy to compare how much the InvokeDynamic instruction can contribute to performance boost. I wonder if it can achieve near Java performance parity.
Fun fact: Nashorn is the German word for a Rhinoceros and the literal translation would be "Nosehorn".<p>And according to Wikipedia: The word rhinoceros is derived through Latin from the Ancient Greek: ῥῑνόκερως, which is composed of ῥῑνο- (rhino-, "nose") and κέρας (keras, "horn").
Does anyone know if this project would obviate Rhino? I'd always sort of assumed that its maintenance was a bit of a low priority for Mozilla, but after seeing the bits of praise in this thread for Rhino perhaps it's not as neglected as I'd suspected.
For others who are interested in fast JS in Java, we've been working on a embedding V8 into clojure using JNA. A working prototype that's good enough for us is at <a href="https://github.com/circleci/clj-v8" rel="nofollow">https://github.com/circleci/clj-v8</a>.<p>I'm using it to port dieter (clojure asset pipeline we to serve <a href="https://circleci.com" rel="nofollow">https://circleci.com</a> [<a href="https://github.com/edgecase/dieter" rel="nofollow">https://github.com/edgecase/dieter</a> ]) from Rhino to Dieter. Our current 100s asset compiles are unbearable, and are only about 4s with V8.
Interesting. I'm no JVM expert but it seems like they will be leveraging the aforementioned MethodHandles and InvokeDynamic for speed gains with JS.<p>I'm interested in how this will stack up to Rhino over the long term not just in performance but especially in ease of use.<p>Rhino is ridiculously easy to use and the "javaToJs" method(s) are wonderful.<p>Can anybody shed light on any over newer JVM features these guys are planning on utilizing (and why)?
I was a bit surprised to see the title here, because the Nashorn project isn't new - what's new is that it is now an OpenJDK project. Oracle has been working on it for a while, it was first announced in July 2011.<p>More info: <a href="http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)" rel="nofollow">http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)</a>
There is someone who already ported V8 as an implementation of JSR223: <a href="http://code.google.com/p/jav8/" rel="nofollow">http://code.google.com/p/jav8/</a><p>Had a try and it seems promising. The only drawback I see is that there are still bugs, and the owner is the sole developer for the project, and he seem to have plenty of other projects going on...
This is good news for everyone.<p>To have real good traction it must be easy to develop the nodejs standard library on it. If this happens, well, it would be pretty awesome. How are they going to manage the async structure for calls to other JVM compatible languages?
From the post: "This project intends to enable Java developers to embed JavaScript in Java applications and to develop free standing JavaScript applications using the jrunscript command line tool."