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