Off with its head: Nashorn JavaScript Engine may soon be deprecated

The Nashorn JavaScript engine was first incorporated into JDK 8, which was released in March 2014. It seems that its life might be shorter than we thought. What’s the reason? “Challenging to maintain,” as explained in JEP 335.
Nashorn JavaScript Engine: Another one bites the dust
Have you ever used Nashorn? If you’re interested, you might want to put it on your to-do list because the Nashorn JavaScript script engine and APIs, as well as the jjs
tool might soon be deprecated, according to JEP 335.
Before Nashorn, there was Rhino, an open-source implementation of JavaScript written entirely in Java. JDK 8 was shipped with an engine called Oracle Nashorn, which provided “better compliance with the ECMA normalized JavaScript specification and better runtime performance through invokedynamic-bound call sites.”
Here’s the motivation behind JEP 335:
When it was released, it was a complete implementation of the ECMAScript-262 5.1 standard.
With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain.
While it personally saddens me to see #Nashorn go, it’s understandable – keeping the pace is hard with a small team, and #GraalVM‘s JS implementation is definitely fast. #Nashorn paved part of the way.
— Michael Haupt (@haupz) June 6, 2018
However, this deprecation will not affect the javax.script
API.
Nashorn is just one of the three JDK modules that will be terminally deprecated, therefore it is annotated with @Deprecated(forRemoval=true)
:
jdk.scripting.nashorn
— contains thejdk.nashorn.api.scripting
andjdk.nashorn.api.tree
packages.jdk.scripting.nashorn.shell
— contains thejjs
tool. Runningjjs
will display a warning:Warning: The jjs tool is planned to be removed from a future JDK release.jdk.dynalink
— contains the Dynalink support library.
Note: A separate JEP will be filed for the actual removal of the types and modules in a future JDK feature release.
SEE ALSO: Keeping track: Three new JEPs targeted to JDK 11
So what should you use now?
A viable alternative seems to be GraalJS, which uses Oracle Labs’ Truffle technology and may soon be publicly available as a Java module. Since GraalJS offers most of the same functionality as Nashorn but with better performance, you should probably look into it.
However, removing Nashorn doesn’t come without risks: for starters, “certain applications will no longer run because of the expectation that JavaScript is present.” The problem is that “the breadth of Nashorn usage has not been easy to track” but this is where you come into play.
If you’re using Nashorn, you should give them feedback – this will provide better insight into actual Nashorn usage.
asap
Is https://bugs.openjdk.java.net/browse/JDK-8202786 the right place to comment on this JEP? I don’t have a JIRA account at bugs.openjdk.java.net? What now?
I’m afraid I can’t answer this question but if you ask around (on Twitter, for example) I’m sure someone can help you. Sorry I couldn’t do more
The ‘discussion ‘ field in the JEP lists the openjdk mailing list to which you can send comments. This does not require a JIRA login but you may need to subscribe to the mailing list.
What’s the best way to give them feedback on this?
Nashorn is awesome, I’d hate to see it removed. Any system that needed a scenario-specific feature I could achieve using Nashorn. We used nashorn to create an extremely powerful scripting API to sit on top of our Java game’s engine, plus it’s so easy to work with our map designer is developing scripts for maps all by himself.