New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Thu Jun 7 10:35:25 UTC 2018

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