New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine

Simone Bordet simone.bordet at
Wed Jun 6 22:07:49 UTC 2018


On Wed, Jun 6, 2018 at 10:18 PM, Darrel Ross < at> wrote:
> If we remove Nashorn are we seeking to replace with something else (like
> V8) or dropping support for running JavaScript in Java altogether?
> I would be much more willing to give up Nashorn if it was going to be
> replaced with something better, but I have worked on projects that would
> have failed had we not been able to utilize Nashorn/Rhino.
> It is a great way to integrate Java and JavaScript code.
> Simply saying JavaScript is a fast changing environment is not, in my
> opinion, an argument to drop support.   Tools like Babel exist to help make
> the quickly changing landscape easier to navigate. I think a much stronger
> solution would be to find ways to allow users to use these tools rather
> than cut support altogether.
> JavaScript is perhaps the most ubiquitous language in the programmer's
> toolbox.  All a user needs to have installed is a browser to run it.  Java
> being able to run it makes it a much stronger platform.  I am not saying
> Java should seek to compete with Node, and would argue that a JS
> application should probably not be run on the JRE, but there are strong use
> cases for a hybrid approach.
> If I am misreading the JEP please clarify.  But dropping a feature that
> already exists, unless its existence prevents future development and
> features, is hardly ever a good idea.

The JEP *hints* that it *may* be replaced with GraalJS.

I maintain a library that uses heavily Rhino/Nashorn, and I second
Darrel that I would not like to see such functionality just go away
without replacement.
It would be good if a precise statement about a replacement is made in
the JEP rather than a possibilistic one.


Simone Bordet
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

More information about the jdk-dev mailing list