simone.bordet at gmail.com
Wed Jun 6 22:07:49 UTC 2018
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
> 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.
> 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.
> 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
It would be good if a precise statement about a replacement is made in
the JEP rather than a possibilistic one.
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