Jim Laskey 提议将 Nashorn 作为 OpenJDK 的 JavaScript 引擎

近日，Oracle 的多语言领导 Jim Laskey 提议将一个新的基于 JVM 的 JavaScript 实现 Nashorn 作为 OpenJDK 项目。Nashorn 是 Rhino 的后继，而 Rhino 则是目前的 JVM JavaScript 实现，它起始于 1997 年的 Netscape，并且经过一些细微的修改后随 2006 年 12 月的 Java SE 6 一同发布。Nashorn 则计划随 Java 8 一同发布并作为其一部分而存在。

Laskey 在其 OpenJDK 的项目提案中说到“Nashorn 的目标是在原生 JVM 上提供一个轻量级、高性能的 JavaScript”：

该项目的范围包括但不限于一个解析器 API（扫描 JavaScript 源代码）、一个编译器（将解析器中的抽象语法树 AST 转换为 JVM 字节码）及一个运行时（支持上述生成的字节码的执行）。该环境中 JavaScript 的执行将与 ECMA-262 5.1 一致，并且会随着标准的不断演进而适应于新的指南。

虽然使用了与 Rhino 相关的名字，但 Nashorn（德语的 rhinoceros）却是个全新的代码基，充分利用了 Java 7 的 InvokeDynamic 字节码指令。其实现要比 Rhino 小且快，这使得它更加适合于运行在嵌入式 / 移动设备上；比如说，它既能运行在 Beagle Board 上，也能运行在 Raspberry Pi 上。

Laskey 在去年 9 月的 JavaOne 上说到，团队正在研究其他 JavaScript 实现的性能，因此其性能应该能与现代浏览器一较高下。此外，Twitter 的 Sam Pullara 还介绍了他是如何使用 Nashorn 来渲染 Mustache.js 模板的。

一切都正常，我根本没有遇到过 Nashorn 的正确性问题。在性能方面，对于大多数颇具挑战的测试，Nashorn 要比 Rhino 快 20 多倍。

此外，NetBeans 团队已经在 Nashorn 基础之上完全重写了其 JavaScript 实现。对于有大量 JavaScript 文件需要扫描的项目来说，变化的结果就是 IDE 启动时间的大幅降低。

除了与 Rhino 相比性能上的提升外，Nashorn 相对于其他 JavaScript 实现来说的一个优势在于它可以访问众多的 Java 库，包括客户端的 JavaFX 及服务端的 JSP。为了支持这种交互，Nashorn 使用了 Dynalink ——基于 Apache 许可的开源元对象协议，构建在 InvokeDynamic 之上，由 Attila Szegedi 开发，他从 Twitter 加入了 Oracle。Dynalink 提供了一套约定以在程序执行环境中指定更高层次的对象操作，对于普通的 Java 对象它提供了一个链接器。

现在 Nashorn 提案已经有了一个专门的博客。当Nashorn 能够100% 兼容于ECMA-262 时，OpenJDK 项目的工作将会专注在性能以及通用性上。潜在的OpenJDK 合作者包括Twitter、IBM 与Red Hat。

查看英文原文： Nashorn Proposed as Replacement JavaScript Engine for OpenJDK