6 ms·

New Project: Nashorn – Lightweight High-Performance JavaScript Runtime in Java

97 points by EzGraphs 14y ago

EzGraphs 14y ago
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."
bascule 14y ago
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. If you're interested in InvokeDynamic, perhaps you'll check out the slides on a talk I gave about it: https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to-hotspot https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to...
jschrf 14y ago
Interesting. I'm no JVM expert but it seems like they will be leveraging the aforementioned MethodHandles and InvokeDynamic for speed gains with JS. 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. Rhino is ridiculously easy to use and the "javaToJs" method(s) are wonderful. Can anybody shed light on any over newer JVM features these guys are planning on utilizing (and why)?
insin 14y ago
At JavaOne this year, the Nashorn team were also demoing Node.jar, a port of the Node.js APIs which runs on Nashorn. The talk one of the team members gave [1] on invokeDynamic and their under-the-hood Dynalink [2] library was pretty interesting. Links to all the Nashorn sessions at JavaOne are available on their blog [3]. [1] https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=5251 https://oracleus.activeevents.com/connect/sessionDetail.ww?S... [2] http://szegedi.github.com/dynalink/ http://szegedi.github.com/dynalink/ [3] https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashorn_blog https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashor...
tantalor 14y ago
> The goal is to provide a lightweight high performance JavaScript on a native JVM. Can somebody please explain what a "native" JVM is?
- svachalek 14y ago
  I believe it's in reference to a JVM that compiles to native code, rather than a naive interpreted one (most of which went extinct a decade ago).
- chadrs 14y ago
  Seems like the more ambiguous term here is "lightweight."
- ddimitrov 14y ago
  By "native" they mean JVM-native (not OS-native). I believe what they really mean is that they use JVM primitives for dispatch, as opposed to building their own using functor objects and reflection-like API (which was the only way to implement MOP pre-InvokeDynamic). It is a bit misleading as there is still a lot that would have to be be emulated - the JVM does not support open types and the Java is centered around classes, which makes prototype mutation hard to implement efficiently ( InvokeDynamic somewhat helps, but would still impose a performance penalty when the prototype is changed). See also John Rose's article about species: https://blogs.oracle.com/jrose/entry/larval_objects_in_the_vm https://blogs.oracle.com/jrose/entry/larval_objects_in_the_v...
chubbard 14y ago
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.
- pbiggar 14y ago
  What does it mean to be about 1.6x Java's performance? Can you be specific - it doesn't seem to mean much since its implemented on the JVM. Also, I've been using it recently and "dog slow" is how I would describe it.
  - scubaguy 14y ago
    It means algorithms runs 1.6x faster within Rhino. A JVM implemented in Rhino that runs Rhino within the JS-JVM will run even faster - roughly 2.56x faster.
    - Cthulhu_ 14y ago
      Which algorithms, what implementations thereof?
    - jhdevos 14y ago
      Wow! So, with an infinite stack of Rhino inside JVM inside Rhine ..... you could get infinite performance! Cool....
      - _quasimodo 14y ago
        It's Rhinos all the way down ...
  - chubbard 14y ago
    Roughly performance tests have shown: Java Performance (ms) * 1.6 = Compiled Rhino Performance (ms). So Rhino is about 60% slower than comparable Java code if you compile it to byte code on average.
kibwen 14y ago
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.
- msgilligan 14y ago
  Nashorn will not be fully backward compatible with Rhino. Nashorn will be very ECMA compliant, but will not implement some Mozilla and/or Rhino-specific extensions. So not all Rhino-based projects will be able to easily migrate. But it's not hard to imagine that Nashorn will divert attention and resources away from Rhino. (I believe I got the above information from the MP4 of the JavaOne presentation that can be found here: https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4082&tclass=popup https://oracleus.activeevents.com/connect/sessionDetail.ww?S...)
- msgilligan 14y ago
  I should add that a modified version of Rhino has been bundled with the JVM since Java 6 (aka 1.6), but it is likely (if not already announced) that future releases of Java from Oracle will bundle Nashorn instead.
pbiggar 14y ago
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 https://github.com/circleci/clj-v8 https://github.com/circleci/clj-v8. I'm using it to port dieter (clojure asset pipeline we to serve https://circleci.com https://circleci.com [https://github.com/edgecase/dieter https://github.com/edgecase/dieter ]) from Rhino to Dieter. Our current 100s asset compiles are unbearable, and are only about 4s with V8.
yuchi 14y ago
This is good news for everyone. 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?
Scotchy 14y ago
There is someone who already ported V8 as an implementation of JSR223: http://code.google.com/p/jav8/ http://code.google.com/p/jav8/ 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...
rb2k_ 14y ago
Fun fact: Nashorn is the German word for a Rhinoceros and the literal translation would be "Nosehorn". And according to Wikipedia: The word rhinoceros is derived through Latin from the Ancient Greek: ῥῑνόκερως, which is composed of ῥῑνο- (rhino-, "nose") and κέρας (keras, "horn").
- throawaypronuc 14y ago
  Also, the correct pronunciation is "naaas-horn" ;-)
  - danneu 14y ago
    A throwaway account just to chime in the pronunciation. Is this what the world is coming to?
- ajuc 14y ago
  In Polish it's similiar - rhinoceros is "Nosorożec" which means "[with] horny nose" literally. Unicorn is "Jednorożec" which means "[with] one horn".
borplk 14y ago
I just wonder what non-technical people with no knowledge of this kind of thing will think if they read a title like this.
vetler 14y ago
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. More info: http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine) http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)
jebberjeb 14y ago
Is anyone from the Rhino project going to be involved with Nashorn?

97 points by EzGraphs 14y ago

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

bascule 14y ago

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. If you're interested in InvokeDynamic, perhaps you'll check out the slides on a talk I gave about it: https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to-hotspot https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to...

jschrf 14y ago

Interesting. I'm no JVM expert but it seems like they will be leveraging the aforementioned MethodHandles and InvokeDynamic for speed gains with JS. 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. Rhino is ridiculously easy to use and the "javaToJs" method(s) are wonderful. Can anybody shed light on any over newer JVM features these guys are planning on utilizing (and why)?

insin 14y ago

At JavaOne this year, the Nashorn team were also demoing Node.jar, a port of the Node.js APIs which runs on Nashorn. The talk one of the team members gave [1] on invokeDynamic and their under-the-hood Dynalink [2] library was pretty interesting. Links to all the Nashorn sessions at JavaOne are available on their blog [3]. [1] https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=5251 https://oracleus.activeevents.com/connect/sessionDetail.ww?S... [2] http://szegedi.github.com/dynalink/ http://szegedi.github.com/dynalink/ [3] https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashorn_blog https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashor...

tantalor 14y ago

> The goal is to provide a lightweight high performance JavaScript on a native JVM. Can somebody please explain what a "native" JVM is?

svachalek 14y ago
I believe it's in reference to a JVM that compiles to native code, rather than a naive interpreted one (most of which went extinct a decade ago).
chadrs 14y ago
Seems like the more ambiguous term here is "lightweight."
ddimitrov 14y ago
By "native" they mean JVM-native (not OS-native). I believe what they really mean is that they use JVM primitives for dispatch, as opposed to building their own using functor objects and reflection-like API (which was the only way to implement MOP pre-InvokeDynamic). It is a bit misleading as there is still a lot that would have to be be emulated - the JVM does not support open types and the Java is centered around classes, which makes prototype mutation hard to implement efficiently ( InvokeDynamic somewhat helps, but would still impose a performance penalty when the prototype is changed). See also John Rose's article about species: https://blogs.oracle.com/jrose/entry/larval_objects_in_the_vm https://blogs.oracle.com/jrose/entry/larval_objects_in_the_v...

chubbard 14y ago

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.

pbiggar 14y ago
What does it mean to be about 1.6x Java's performance? Can you be specific - it doesn't seem to mean much since its implemented on the JVM. Also, I've been using it recently and "dog slow" is how I would describe it.
- scubaguy 14y ago
  It means algorithms runs 1.6x faster within Rhino. A JVM implemented in Rhino that runs Rhino within the JS-JVM will run even faster - roughly 2.56x faster.
  - Cthulhu_ 14y ago
    Which algorithms, what implementations thereof?
  - jhdevos 14y ago
    Wow! So, with an infinite stack of Rhino inside JVM inside Rhine ..... you could get infinite performance! Cool....
    - _quasimodo 14y ago
      It's Rhinos all the way down ...
- chubbard 14y ago
  Roughly performance tests have shown: Java Performance (ms) * 1.6 = Compiled Rhino Performance (ms). So Rhino is about 60% slower than comparable Java code if you compile it to byte code on average.

kibwen 14y ago

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.

msgilligan 14y ago
Nashorn will not be fully backward compatible with Rhino. Nashorn will be very ECMA compliant, but will not implement some Mozilla and/or Rhino-specific extensions. So not all Rhino-based projects will be able to easily migrate. But it's not hard to imagine that Nashorn will divert attention and resources away from Rhino. (I believe I got the above information from the MP4 of the JavaOne presentation that can be found here: https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4082&tclass=popup https://oracleus.activeevents.com/connect/sessionDetail.ww?S...)
msgilligan 14y ago
I should add that a modified version of Rhino has been bundled with the JVM since Java 6 (aka 1.6), but it is likely (if not already announced) that future releases of Java from Oracle will bundle Nashorn instead.

pbiggar 14y ago

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 https://github.com/circleci/clj-v8 https://github.com/circleci/clj-v8. I'm using it to port dieter (clojure asset pipeline we to serve https://circleci.com https://circleci.com [https://github.com/edgecase/dieter https://github.com/edgecase/dieter ]) from Rhino to Dieter. Our current 100s asset compiles are unbearable, and are only about 4s with V8.

yuchi 14y ago

This is good news for everyone. 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?

Scotchy 14y ago

There is someone who already ported V8 as an implementation of JSR223: http://code.google.com/p/jav8/ http://code.google.com/p/jav8/ 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...

rb2k_ 14y ago

Fun fact: Nashorn is the German word for a Rhinoceros and the literal translation would be "Nosehorn". And according to Wikipedia: The word rhinoceros is derived through Latin from the Ancient Greek: ῥῑνόκερως, which is composed of ῥῑνο- (rhino-, "nose") and κέρας (keras, "horn").

throawaypronuc 14y ago
Also, the correct pronunciation is "naaas-horn" ;-)
- danneu 14y ago
  A throwaway account just to chime in the pronunciation. Is this what the world is coming to?
ajuc 14y ago
In Polish it's similiar - rhinoceros is "Nosorożec" which means "[with] horny nose" literally. Unicorn is "Jednorożec" which means "[with] one horn".

borplk 14y ago

I just wonder what non-technical people with no knowledge of this kind of thing will think if they read a title like this.

vetler 14y ago

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. More info: http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine) http://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)

jebberjeb 14y ago

Is anyone from the Rhino project going to be involved with Nashorn?