New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

[Alan Bateman]

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