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。