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

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

Hi,

On Wed, Jun 6, 2018 at 10:18 PM, Darrel Ross <darrelross.java at gmail.com> 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.

Thanks!

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