Oracle通过宣布弃用，最终将从未来所有的JDK中删除。ECMAScript的语言结构变化太快，Oracle发现，维护Nashorn JavaScript引擎变得非常困难。

Nashorn最初是在JDK 8中引入的，用于取代Rhino脚本引擎。当其发布时，Nashorn是的完整实现，增强了Java和JavaScript的兼容性。最近还增加了新的。借助Nashorn，开发人员可以从JavaScript调用Java代码，也可以从Java代码调用JavaScript函数。Nashorn可以作为Java应用程序的嵌入式解释器，提供使用Nashorn命令行工具从命令行运行JavaScript的能力。当在Java中对JavaScript代码求值时，Nashorn实现了javax.script API。Oracle表示，弃用Nashorn不会影响javax.script API。

移除Nashorn后，有些应用程序可能会因为需要JavaScript而无法运行。

具体要弃用的模块如下：

• jdk.scripting.nashorn——包含jdk.nashorn.api.scripting和jdk.nashorn.api.tree包；\\t
• jdk.scripting.nashorn.shell——包含jjs工具；\\t
• jdk.dynalink——包含Dynalink支持库。\

Oracle实验室高级研究总监表示，是一个不错的替代方案，与Nashorn相比，它的性能更好，与ECMAScript的兼容性也更好。虽然GraalVM现在还没有生产就绪，但Wuerthinger向开发者社区保证，在Nashorn真正弃用之前，基于GraalVM的JavaScript实现将在所有相关平台上实现生产就绪。

\

在Nashorn真正弃用之前，基于的JavaScript实现将在所有相关平台上实现生产就绪。它将提供更好的性能，并且完全兼容ECMAScript的最新标准。

\\

— Thomas Wuerthinger (@thomaswue) 

\

真正要在将来的JDK版本中删除相关的类型和模块，Oracle会提交一份单独的JEP。

开发社区的总体反应是担忧，尤其是那些在业务逻辑中大量使用了Nashorn的。Oracle听上去愿意撤回JEP 335，如果有足够的开发人员反馈的话。

\

还有一种选择是有一组可信赖的开发人员清楚表达今后维护Nashorn的愿望。如果那种情况在这份JEP完善之前出现，那么它还是可以撤回的。如果那是在这份JEP完善之后，但是在Nashorn被移除之前，则可以再提交一份JEP来逆转这次弃用。

\

按照Oracle的说法，Nashorn的使用情况很难跟踪，因此，有任何回退都会及时发布通知，而不管JEP 335是否通过。使用Nashorn的开发人员应该向Oracle提供反馈，以便他们可以更好地了解Nashorn的使用情况。

感兴趣的读者可以通过时刻关注所有Java相关的新闻。

查看英文原文：