6 ms·

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

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

kasperni 6y ago
To add to that. It was previously included directly in the JDK but is now a standalone product.
- billfruit 6y ago
  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.
  - pron 6y ago
    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.
  - usrusr 6y ago
    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.
  - chrisseaton 6y ago
    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.
  - samus 6y ago
    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.
pwdisswordfish0 6y ago
And it's stuck on ES5 from 2009.
postpawl 6y ago
“According to Oracle benchmarks, Nashorn performance is several orders of magnitude faster than the alternative Rhino JavaScript engine.” Interesting
- usrusr 6y ago
  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)
- chrisseaton 6y ago
  > 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.
harrygeez 6y ago
any good reason to use this over v8/Node?
- cogman10 6y ago
  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.
  - theandrewbailey 6y ago
    > (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.
    - KajMagnus 6y ago
      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 https://news.ycombinator.com/item?id=25248748 ) @cogman10 > > Using node/v8 requires another distributable and starting up a new process Precisely
- blackmagicjs 6y ago
  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.
reitzensteinm 6y ago
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.
- KajMagnus 6y ago
  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.
  - reitzensteinm 6y ago
    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.

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

kasperni 6y ago

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

billfruit 6y ago
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.
- pron 6y ago
  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.
- usrusr 6y ago
  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.
- chrisseaton 6y ago
  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.
- samus 6y ago
  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.

pwdisswordfish0 6y ago

And it's stuck on ES5 from 2009.

postpawl 6y ago

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

usrusr 6y ago
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)
chrisseaton 6y ago
> 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.

harrygeez 6y ago

any good reason to use this over v8/Node?

cogman10 6y ago
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.
- theandrewbailey 6y ago
  > (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.
  - KajMagnus 6y ago
    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 https://news.ycombinator.com/item?id=25248748 ) @cogman10 > > Using node/v8 requires another distributable and starting up a new process Precisely
blackmagicjs 6y ago
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.

reitzensteinm 6y ago

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.

KajMagnus 6y ago
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.
- reitzensteinm 6y ago
  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.