New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

[Attila Szegedi]

On 2018. Jun 15., at 14:07, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 15/06/2018 12:40, Attila Szegedi wrote:
>> :
>> It’d be great if we could conceptually unbundle Dynalink from Nashorn for the purpose of this discussion. (For historical reasons, its source code is colocated with Nashorn's, but it can be easily moved elsewhere and there’s no technical reason for keeping it there.)
>> 
> This has already been done, in JDK 9 as part of the JEP 201 effort to reorganize the source code into modules. So while it may have been originally developed along with Nashorn, it is its own module now.
> 
> I suspect the only impediment to it working outside of the JDK is the special handling for @CS methods.

FWIW, @CS is not an issue. Untrusted code can somewhat more weakly detect the @CS annotation by its name instead of by its class.

It’s not so much about it being able to work outside the JDK, but rather about its adoption if every language runtime that wishes to use it would have to carry it as a dependency, and that deters people; e.g. see the effort to use Dynalink as the solution for dynamic invocation in Scala[1]. To quote from there:

"The need to add a runtime dependency was a little off-putting (tilting the balance from "no brainer, let's use this" to "nice to have, but I'd rather not touch our build") , so I welcome the move to standardize the API.”

I suspect there could also be subtle issues if multiple instances of Dynalink through multiple class loaders are floating around instead of a single one (which is guaranteed if it’s in the JDK) (not sure about it though).

Attila.

[1] https://groups.google.com/forum/#!msg/jvm-languages/WGq4BiQ7oz8/-WbMnQOvDgAJ

> 
> -Alan