It's a JEP!

JEP 372: Remove the Nashorn JavaScript Engine

Chris Stewart

The second Java enhancement proposal (JEP) of 2020 has landed! Following JEP 371: Hidden Classes, now we have a second full-fledged candidate JEP with a decent shot at making it into JDK 15. That said, some voices in the community don’t agree with the proposal. Let’s take a closer look.

Jim Laskey, Director of Software Development at Oracle Corporation, has put forward a candidate Java enhancement proposal to remove the long-deprecated Nashorn JavaScript engine, APIs, and jjs tool. The JEP has been proposed to target JDK 15.

JEP 372: Remove the Nashorn JavaScript Engine

In JEP 372, Laskey writes:

The Nashorn JavaScript engine was first incorporated into JDK 8 via JEP 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.

This latter comment is a sentiment mirrored by some in the community.


The aim is to remove two JDK modules: jdk.scripting.nashorn, which contains the jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages, and, containing the jjs tool. Laskey further states that it is not his intention to touch the javax.script API.

SEE ALSO: JEP 371: Hidden Classes in Java

The Nashorn JavaScript engine was deprecated in JDK 11, released in September 2018. As such, Laskey believes developers who use it have had ample time to make alternative arrangements, and that since nobody has “expressed a clear desire to maintain Nashorn in JDK 14 and beyond”, the decision to remove it makes complete sense.

However, some members of the community are less than pleased by this suggestion. User BlueGoliath on reddit wrote: “Not nearly of a positive action as many think it is, IMO. If Oracle/JDK developers are going to drop features like JavaFX and Nashorn like that then people are just going to ignore otherwise centralized and dependable baked-in features for potentially worse off third-party ones. Java has historically been known for being highly backwards compatible and this hurts that perception.”

SEE ALSO: Java trends: Top 10 Frameworks in 2020

At the time of writing, there are no responses on the jdk-dev mailing list debating the merits of this proposal, so we’ll have to wait to find out what the JDK developers think.

Do you have a strong feeling one way or another? Let us know in the comments. Otherwise, why not check out the JEP in all its glory here.

Chris Stewart
Chris Stewart is an Online Editor for He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Inline Feedbacks
View all comments