

New Project: Nashorn – Lightweight High-Performance JavaScript Runtime in Java - EzGraphs
http://mail.openjdk.java.net/pipermail/announce/2012-November/000139.html

======
bascule
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...](https://speakerdeck.com/tarcieri/invokedynamic-your-guide-to-hotspot)

------
insin
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?S...](https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=5251)

[2] <http://szegedi.github.com/dynalink/>

[3]
[https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashor...](https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashorn_blog)

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

~~~
jhdevos
Wow! So, with an infinite stack of Rhino inside JVM inside Rhine ..... you
could get infinite performance! Cool....

~~~
_quasimodo
It's Rhinos all the way down ...

------
rb2k_
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
Also, the correct pronunciation is "naaas-horn" ;-)

~~~
danneu
A throwaway account just to chime in the pronunciation. Is this what the world
is coming to?

------
kibwen
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
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?S...](https://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=4082&tclass=popup))

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

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

------
jschrf
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)?

------
tantalor
> The goal is to provide a lightweight high performance JavaScript on a native
> JVM.

Can somebody please explain what a "native" JVM is?

~~~
ddimitrov
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_v...](https://blogs.oracle.com/jrose/entry/larval_objects_in_the_vm)

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

------
Scotchy
There is someone who already ported V8 as an implementation of JSR223:
<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...

------
yuchi
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?

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

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

