New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

[Jonathan Bluett-Duncan]

Hi Alan and James,

JUnit 5 allows users to disable tests using @DisableIf
<https://junit.org/junit5/docs/5.2.0/user-guide/#writing-tests-conditional-execution-scripts>,
which AFAICT depends on the javax.script API and chooses Nashorn as the
default scripting engine. However, @DisableIf is currently an experimental
feature, and I don't think JUnit 5 depends on Nashorn's internals, so it's
not clear to me how important it is to the JUnit 5 developers that Nashorn
or some other JavaScript engine exists in Java 11+...

Just my 2 cents. :)

Cheers,
Jonathan

On 7 June 2018 at 11:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
> 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
>