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

短命女 2022-04-11 13:58 191阅读 0赞

本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2013/01/Nashorn-proposal

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

Laskey在其OpenJDK的[项目提案][Link 1]中说到“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提案已经有了一个专门的[博客][Link 2]。当Nashorn能够100%兼容于ECMA-262时，OpenJDK项目的工作将会专注在性能以及通用性上。潜在的OpenJDK合作者包括Twitter、IBM与Red Hat。

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

[Link 1]: http://mail.openjdk.java.net/pipermail/announce/2012-November/000139.html
[Beagle Board]: http://beagleboard.org/
[Raspberry Pi]: http://www.raspberrypi.org/
[Mustache.js]: https://github.com/janl/mustache.js
[Dynalink]: https://github.com/szegedi/dynalink
[Link 2]: https://blogs.oracle.com/nashorn/entry/welcome_to_the_nashorn_blog
[Nashorn Proposed as Replacement JavaScript Engine for OpenJDK]: http://www.infoq.com/news/2012/11/Nashorn-proposal