Oracle announced via JDK Enhancement Proposal (JEP) 355 that the Nashorn JavaScript Engine may soon be deprecated and eventually removed from all future Java Development Kits (JDKs). With the rapid pace at which the ECMAScript language constructs have changed, Oracle finds the Nashorn JavaScript Engine challenging to maintain.
Nashorn was originally introduced incorporated into JDK 8 as a replacement for the Rhino scripting engine. When Nashorn was released, it was a complete implementation of the ECMAScript-262 5.1 standard that enhanced compatibility between Java and JavaScript. There were recent additions that included new ECMAScript 6 (ES6) features. With Nashorn, developers have the ability to invoke Java code from JavaScript and also invoke JavaScript functions from within Java code. Nashorn can be embedded as an interpreter in Java applications and provides the capability to run JavaScript from the command-line using Nashorn's command-line tool, jjs. When evaluating JavaScript code from Java, Nashorn implements the javax.script API. Oracle states the deprecation of Nashorn will not affect the javax.script API.
By removing Nashorn, some applications may no longer run because of an expectation of JavaScript’s presence.
The specific JDK modules to be deprecated include:
jdk.scripting.nashorn- contains thejdk.nashorn.api.scriptingandjdk.nashorn.api.treepackagesjdk.scripting.nashorn.shell- contains thejjstooljdk.dynalink- contains the Dynalink support library
Thomas Wuerthinger, senior research director at Oracle Labs, stated that GraalVM is a good alternative with more performance and better ECMAScript compatibility than Nashorn. Although GraalVM is not available in production yet, Wuerthinger assures the development community that the JavaScript implementation based on GraalVM will be production-ready on all relevant platforms before Nashorn is deprecated.
The JavaScript implementation based on #GraalVM will be production-ready on all relevant platforms before Nashorn is deprecated. It will give you better performance and is fully compliant to the latest ECMAScript standard.
— Thomas Wuerthinger (@thomaswue) June 7, 2018
A separate JEP will be filed for the actual removal of the types and modules in a future JDK feature release.
The overall feedback from the development community has been that of concern, especially from those that use Nashorn heavily for business logic. Oracle sounds willing to revert JEP 335 if there is enough developer feedback.
An alternative is for a set of credible developers to express a clear desire to maintain Nashorn going forward. If that happens before this JEP is integrated then this JEP can be withdrawn. If that happens after this JEP is integrated, but before Nashorn is removed, then a follow-on JEP can revert the deprecation.
Per Oracle, Nashorn usage is very difficult to track, so ideally any pushback will inform whether JEP 335 goes through or not. For developers using Nashorn, feedback should be provided to Oracle as this will give better insight into actual Nashorn usage.
Readers can also keep up-to-date with all Java-related news by visiting the InfoQ Java homepage.