JDK-8202786 : JEP 335: Deprecate the Nashorn JavaScript Engine for Removal
  • Type: JEP
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Priority: P3
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 11
  • Submitted: 2018-05-08
  • Updated: 2024-04-25
  • Resolved: 2018-07-17
Related Reports
Relates :  
Relates :  
Sub Tasks
JDK-8204492 :  
JDK-8205932 :  
Description
Summary
-------

Deprecate the Nashorn JavaScript script engine and APIs, and the `jjs`
tool, with the intent to remove them in a future release.

Motivation
----------

The Nashorn JavaScript engine was first incorporated into JDK 8 via
[JEP 174](http://openjdk.java.net/jeps/174) as a replacement for the Rhino
scripting engine.  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.

Non-Goals
---------

This deprecation does not affect, in any way, the `javax.script` API.

Description
-----------

Two [JDK modules](http://openjdk.java.net/jeps/200#Design-principles) will be
terminally deprecated, that is, annotated with `@Deprecated(forRemoval=true)`:

- `jdk.scripting.nashorn` -- contains the `jdk.nashorn.api.scripting` and 
  `jdk.nashorn.api.tree` packages.

- `jdk.scripting.nashorn.shell` -- contains the `jjs` tool. Running `jjs`
  will display a warning:
  
    Warning: The jjs tool is planned to be removed from a future JDK release.

A separate JEP will be filed for the actual removal of the types and modules
in a future JDK feature release.

Alternatives
------------

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.

Risks and Assumptions
---------------------

The risk of removing Nashorn is that certain applications will no longer run
because of the expectation that JavaScript is present.  The breadth of Nashorn
usage has not been easy to track. It is hoped that feedback for this JEP might
provide better insight into actual Nashorn usage.

Comments
I understand the challenge of having to maintain a javascript implementation. But there are applications using it (like the one I'm maintaining). If nashorn is removed, can it be made available as a pluggable javax.script option? In that way existing applications can keep functioning.
25-02-2020