Oracle 通过 JDK 增强提案(JEP)355 宣布弃用 Nashorn JavaScript 引擎,最终将从未来所有的 JDK 中删除。ECMAScript 的语言结构变化太快,Oracle 发现,维护 Nashorn JavaScript 引擎变得非常困难。
Nashorn 最初是在 JDK 8 中引入的,用于取代 Rhino 脚本引擎。当其发布时,Nashorn 是 ECMAScript-262 5.1 的完整实现,增强了 Java 和 JavaScript 的兼容性。最近还增加了新的 ECMAScript 6(ES6)特性。借助 Nashorn,开发人员可以从 JavaScript 调用 Java 代码,也可以从 Java 代码调用 JavaScript 函数。Nashorn 可以作为 Java 应用程序的嵌入式解释器,提供使用 Nashorn 命令行工具 jjs 从命令行运行 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
包;jdk.scripting.nashorn.shell
——包含jjs
工具;jdk.dynalink
——包含 Dynalink 支持库。
Oracle 实验室高级研究总监 Thomas Wuerthinger 表示, GraalVM 是一个不错的替代方案,与 Nashorn 相比,它的性能更好,与 ECMAScript 的兼容性也更好。虽然 GraalVM 现在还没有生产就绪,但 Wuerthinger 向开发者社区保证,在 Nashorn 真正弃用之前,基于 GraalVM 的 JavaScript 实现将在所有相关平台上实现生产就绪。
在 Nashorn 真正弃用之前,基于#GraalVM 的 JavaScript 实现将在所有相关平台上实现生产就绪。它将提供更好的性能,并且完全兼容 ECMAScript 的最新标准。
— Thomas Wuerthinger (@thomaswue) 2018 年 6 月 7 日
真正要在将来的 JDK 版本中删除相关的类型和模块,Oracle 会提交一份单独的 JEP。
开发社区的总体反应是担忧,尤其是那些在业务逻辑中大量使用了 Nashorn 的。Oracle 听上去愿意撤回 JEP 335,如果有足够的开发人员反馈的话。
还有一种选择是有一组可信赖的开发人员清楚表达今后维护 Nashorn 的愿望。如果那种情况在这份 JEP 完善之前出现,那么它还是可以撤回的。如果那是在这份 JEP 完善之后,但是在 Nashorn 被移除之前,则可以再提交一份 JEP 来逆转这次弃用。
按照 Oracle 的说法,Nashorn 的使用情况很难跟踪,因此,有任何回退都会及时发布通知,而不管 JEP 335 是否通过。使用 Nashorn 的开发人员应该向 Oracle 提供反馈,以便他们可以更好地了解 Nashorn 的使用情况。
感兴趣的读者可以通过 InfoQ Java 首页时刻关注所有 Java 相关的新闻。
评论