New candidate JEP: 335: Deprecate the Nashorn JavaScript Engine
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