Such a short life

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

Gabriela Motroc
© Shutterstock / Etienne Outram

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.

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 the jdk.nashorn.api.scripting andjdk.nashorn.api.tree packages.
  • — contains the jjs tool. Running jjs 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.


Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments
Dr. Nils Jena
Dr. Nils Jena
3 years ago

Is the right place to comment on this JEP? I don’t have a JIRA account at What now?

Helpful barista
Helpful barista
Reply to  Dr. Nils Jena
3 years ago

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.

3 years ago

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.