New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

Luigi Dell'Aquila luigi.dellaquila at
Thu Jun 7 10:44:56 UTC 2018

Hi Alan,

I think most of the panic here comes from the sentence "The risk of
removing Nashorn is that certain applications will no longer run because of
the expectation that JavaScript is present".
Until now we gave it for granted, if it's not going to be the case in the
future we really would like to know it...



2018-06-07 12:35 GMT+02:00 Alan Bateman <Alan.Bateman at>:

> There are several replies from people that are using Nashorn but one thing
> that is not clear from any of the mails so far is whether these usages are
> via the javax.script API or by code making direct usage of Nashorn APIs. I
> assume it is mostly the former, in which case the applications or libraries
> concerned might not care (EMCAScript version support/compliance details
> aside) if the JavaScript implementation is deployed on the class path or
> module path. If this assumption is correct, and if the
> jdk.scripting.nashorn module is removed as envisaged by the draft JEP, then
> the disruption should be mostly around moving the reliance on the version
> bundled with the JDK to needing it be deployed on the class or module path.
> Jim - one small bit of feedback on the draft is that most developers
> aren't going to see the deprecation warnings (I assume very few modules
> will `requires jdk.scripting.nashorn` or `requires jdk.dynalink`). They
> will see warnings if they use the `jjs` tool but I assume many usages will
> be via the scripting API so there won't be any warning. You might have
> looked at this already but having some way to run an application so that it
> emits a warning if Nashorn is used could be useful, esp. in large
> environments where it might not be immediately obvious if one of the
> libraries is using it. One recent example of this type of thing was the
> misfeature know as extension mechanism. In JDK 8 there was a VM option to
> detect usages of the then-deprecated feature before it was finally removed
> in JDK 9.
> -Alan

More information about the jdk-dev mailing list