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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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).
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)
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.)
34 comments
[ 0.28 ms ] story [ 76.7 ms ] threadInteresting
...and several orders of magnitude slower than the other alternative JavaScript engine, GraalJS, which they don't mention for some reason.
Using node/v8 requires another distributable and starting up a new process.
I used it to add Markdown to a Java app, because JS-based Markdown libraries were better than Java-based ones.
(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
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 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.
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.
Graal JS is much closer to being on par with modern JS engines. Nashorn is on par with JS engines from 10 years ago.
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...
> 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).
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 ..."
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
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.)