JSR-292和多语言VM

从2007年初开始的JSR-292目的在于提高在Java虚拟机（JVM）上对动态语言的支持。一直以来主要的精力都集中在JVM的invokedynamic指令，不过最近的新动向包括了创建多语言虚拟机的项目。John Rose总结了最近一次会议的讨论结果：

• 我们对JVM的指令架构作了重大的改变。
• 一批新的动态语言的出现是其诱因。我们有商业上的理由让JVM支持这些语言。
• 专家组一致同意：我们希望尽早交给公众评议。这意味着要产生一个EDR（早期草案评议，JCP的要求）。
• 为了公开我们的验证性设计，首先需要通过“红脸测试（red face test）”。也就是说，我们作为专家组，必须觉得设计显示出的发展方向值得深入阐释和改进。因为EDR规范并不是一个要求投票的里程碑版本，所以规范不完整或者存在未解决的问题是允许的。
• 最初的JSR 292不仅包括invokedynamic，还包括对类的一些修改或扩展。根据最近的经验，除了invokedynamic之外还需要稍微做一些行为上的扩展（method handles、autonomous methods等）。还需要进一步讨论。
• OpenJDK的一个开源子项目将会帮助创建JSR 292的RI（参考实现，JCP的要求）。
• 这个项目（MLVM）很可能还会引入其他更改。哪些更改已经准备好标准化，哪些要推到MR（维护版）或者另一个JSR，都要由我们专家组来决定。

为了以上目的，John Rose在OpenJDK的邮件列表上提议了一个多语言VM项目：

这个项目鼓励为有效地支持Java以外的语言，进行各种JVM特性的原型试验。

项目的重点将放在用普适性的扩展来补足现有的字节码及执行架构，而不提倡只为一种语言增加新特性，或者加入不相关的新执行架构。

重点还包括消灭那些已经被成功且有影响力的语言在实现中发现的“疼痛点”，而反对为未经证明的特性或者花瓶语言去做一些纯理论的工作。

提议得到的反响大多是正面的：“你吸引到我了”，“很高兴Sun仍然能看出Java的平台本质”。反响也是建设性的，既有Neal Gafter提议的算术精度和效率的矛盾，Attila提议的元对象协议，还有Remi提议的运行时泛型（reified generics）。

与此同时，人们也意识到了项目规模带来的内在危险。Attila指出了Parrot的前车之鉴：

当然，如果目标太大，就存在迷失方向的危险；Parrot的历史就是一个可怕的先例。

John Rose对此回应说：

是的。如果要全部完成最初列出来的想法，可能要花几十年。（而且这些只是我按照自己的喜好挑出来的一部分想法。）因此有必要先选出最有利的一些项目。

要获得更多信息，请加入JSR-292 Observers列表和JVM Languages群组，盯紧Mercurial项目，当然别忘了留意InfoQ的Java社区。

查看英文原文： JSR-292 and the Multi-Language VM