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

你可能感兴趣的:(Jim Laskey提议将Nashorn作为OpenJDK的JavaScript引擎)