Standalone Nashorn 15.0 is out | Hacker News Reader

Standalone Nashorn 15.0 is out

mail.openjdk.java.net

54 pointspjmlp34 comments

Hasn't Nashorn been superseded by GraalJS?

Is this just for those who are stuck with Nashorn, or will there be new development?

GraalJS is ECMASCript 2020 compatible and is said to rival V8 on performance, so I would've thought it the obvious choice for new projects going forward.

https://github.com/graalvm/graaljs

Edit: found more info about this release in the initial announcement:

https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-Oct...

Isn't GraalJS restricted in usage though? Like it can only be used as part of Oracle GraalVM, not any other JVM distribution?

From the readme:

> The preferred way to run GraalVM JavaScript is from a GraalVM. If you prefer running it on a stock JVM, please have a look at the documentation in RunOnJDK.md.

I'm running it on a stock OpenJDK JVM without any issue, just by including a Maven dependency. For best performance you should run it on GraalVM (where the Community Edition is based on OpenJDK).

Oh that's awesome, thanks for letting me know.

JVMCI (the interface GraalJS uses to talk to the compiler, rather than going through bytecode, as Nashorn does) is now a standard part of OpenJDK.

The GraalJS license is apparently similar to MIT:

https://github.com/graalvm/graaljs/blob/master/LICENSE

"The Universal Permissive License (UPL), Version 1.0"

And about the UPL:

https://tldrlegal.com/license/universal-permissive-license-1...

"... including an explicit patent grant, clear ability to relicense ..."

> Hasn't Nashorn been superseded by GraalJS?

It depends, do you want support for your JVM? If so:

* Graal CE has no support

* Graal EE requires either running on Oracle Cloud or calling Oracle Sales for a custom quote. These are non-starters for many.

* JVMCI requires `-XX:+UnlockExperimentalVMOptions` which often voids support.

* I believe Mandrel is supported but requires RHEL

For the most part yes. The only reason to use this is either you care about the smaller runtime or you have some dependency that can't function without nashorn.

Is GraalJS just an interface to NodeJS, or why do they mention the NodeJS API?

They have both. GraalJS itself is just a JS runtime, but they've also made a separate package that reimplements the Node stdlib (but doesn't work on Windows yet, for example)

Good to know, thanks!

For anyone else wondering what Nashorn is: It is Javascript running in the JVM https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)

I used it back in the day to provide server side rendering for a Clojure/ClojureScript/Reagent web app.

I remember it being a bit of a pig, both in memory consumption and CPU use, but I'm sure that was just relative to the black magic behind V8.

I use it for server side rendering, in a Scala web app. It takes a bit to warm up and JIT compile the Typescript code (transpiled to js), but after that, it's okay fast.

I did a bit comparison with V8 maybe 5+ years ago and at the time, it was about the same speed as V8, from what I could see in a few quick tests — after warmup a lot.

That's very interesting. I am guessing ClojureScript generates a lot more code that runs through interfaces that sophisticated JITs can partially evaluate away.

For us, the performance difference was an order of magnitude, to the point that we were too slow in cases for search engines. We were investigating building an external Node proxy instance to prerender pages.

I sincerely hope there's no flag or simple tweak we were missing. It's possible the instances were starved for memory, for instance.

And it's stuck on ES5 from 2009.

To add to that. It was previously included directly in the JDK but is now a standalone product.

Why do they keep doing that, it makes dependecy management etc, more complicated. Sometime ago they did that with JavaFx, while still retaining AWT as part of JDK: what a baffling move, discard the best GUI framework on the platform, while including the most obsolete one.

Burdening all five users of FX or Nashorn with the one time act of dependency management setup is a much lower cost for java popularity than burdening all other users of java with the repeated minor annoyance of JRE bloat. As a bonus, both have a much better chance of seeing continued development outside of the stifling rigidness of the JRE development process.

It wasn't discarded, just delivered separately. Unlike Swing/AWT, JavaFX is not part of the Java SE standard, so vendors don't have to include it, but users can use it like any library.

The team at Oracle can't be responsible for maintaining such a large set of complex and sometimes niche dependencies - it just isn't realistic or reasonable.

These project operate at a much different pace than the JDK. Actually, it makes everyones life easier: any sane project at scale already uses a dependency management tool, and it's just another entry there. Also, it makes it possible to nail down the JavaFX version that is used. It's one moving target less that varies by JRE version at deployment time and can ruin the show.

“According to Oracle benchmarks, Nashorn performance is several orders of magnitude faster than the alternative Rhino JavaScript engine.”

Interesting

> Nashorn performance is several orders of magnitude faster than the alternative Rhino JavaScript engine

...and several orders of magnitude slower than the other alternative JavaScript engine, GraalJS, which they don't mention for some reason.

I might be wrong but this sounds a lot like you should be wondering what Rhino was (or is, apparently it's still not quite dead yet)

any good reason to use this over v8/Node?

You are using java but want access to Javascript for various reasons. (Maybe you want to add scripting? Maybe you want to use a JS lib? Really sort of depends on the circumstance).

Using node/v8 requires another distributable and starting up a new process.

> (Maybe you want to add scripting? Maybe you want to use a JS lib? Really sort of depends on the circumstance)

I used it to add Markdown to a Java app, because JS-based Markdown libraries were better than Java-based ones.

I use it to add React.js server side rendering to a Scala app

(more details in this comment: https://news.ycombinator.com/item?id=25248748 )

@cogman10

> > Using node/v8 requires another distributable and starting up a new process

Precisely

NodeJS has gone woke and supports Black Lives Matters. They also seem to have a history of social justice battles (as does the company behind V8 that NodeJS is based on, Google). I'm glad for alternatives.

In case anyone wants to see a Java (well, Scala) app that uses Nashorn:

https://insightful.demo.talkyard.io/-17/i-can-no-longer-work...

Is uses Nashorn for server side rendering a React.js Single Page App, calling from Scala to Nashorn running React.js code in the same JVM. (I'm developing it. Hmm I should clean up that demo forum.)

I wonder how performance compares to other JavaScript engines.

It's poor.

Graal JS is much closer to being on par with modern JS engines. Nashorn is on par with JS engines from 10 years ago.

Didn’t they refer developers to use GraalJS in past?

Reply on news.ycombinator.com