JVM 动态语言比武

JVM 在支持多语言方面的能力比较晚才受到 Sun 的重视。Sun 态度上的转变反映出了在 JVM 上工作的广大开发者的口味变化，一些开发者正打算通过动态语言来加速部分开发过程。通过纳入 JSR 223（Java 平台脚本），Sun 开始正式认可这种变化，JSR 223 让 Java SE 6 能够执行用 Ruby、Python、Groovy 或 JavaScript 等动态语言编写的脚本代码。

Travis Jensen 是 SirsiDynix 的一名技术架构师，最近他对Groovy、Jython 和JRuby 进行了一次对比，看看这三种语言是否适合用来给一个Java 开发团队进行Web GUI 开发。他按照以下五条粗略的标准来评估这三种语言：

1、 动态语言与 Java 之间的交互。Jensen 觉得 Groovy 最强，Jython 也相差无几：

“因为 Groovy 支持使用 Java 类型，所以覆盖类的方法可以很直接。实例化一个 Groovy 类和实例化一个 Java 类没什么两样。”

他认为 JRuby 的困难最大：

“从 Java 转到 JRuby 不是一件小事，虽然 JRuby 也是编译成 class 文件。编译器主要还是在加速 JRuby 本身的交互上着墨。”

2、 IDE 支持。因为 SirsiDynix 一律使用 JetBrains 公司的 IDEA，所以这方面的比较不够充分。比如 NetBeans 的 JRuby 插件就没有被纳入评估。Jensen 觉得 IDEA 对 Groovy 的支持让 Groovy 成为明显的胜利者。

3、Java 开发者的学习曲线。Jensen 的结论是 Groovy 又一次胜出：

“因为 Groovy 是 Java 的一个超集，所以从 Java 到 Groovy 的学习曲线是十分平直的。尤其是在 API 方面，它可以直接使用 Java API。说实话我不知道 Groovy 的生产效率是不是像 Python 和 Ruby 那么高，但我没有看到任何反面的证据。我直觉认为 Python 和 Ruby 的库更适合各自语言，因此会有更高的生产效率。”

他还认为尽管 JRuby 被看作是一种生产力非常高的语言，但它带给 Java 开发者的挑战却是最大的：

“由于 Ruby 更接近函数式语言，它的学习曲线是三者之中最高的。它在 Java 库以及原生库方面也存在相同的问题。不过老实说，我认为一旦越过困难的学习门槛，JRuby 的生产效率是最高的。在这方面我对 Ruby 只有敬佩之情。”

4、可供选择的 Web 框架。JRuby 赢得一票：

“凭着直接移植的 Rails，JRuby 得到了最高票数。”

Jython 是三者当中最弱的：

“CPython 有很多不错的选择，而 Jython 却已经两年停滞不前。主要原因有两重：一是 Jython 当前版本是 2.2.1，而 CPython 已经是 2.5 了；二是很多框架都为了性能而要求 C 代码编译。”

5、 社区支持：Jensen 觉得三种语言的社区支持都很优秀，不过 Groovy 稍胜一筹：

“因为 JVM 是 Groovy 的唯一平台，所以整个 Groovy 社区同时也属于 JVM 社区。对于打算部署到 JVM 上的人来说，这一点显然是重要的优势。而且 Groovy 挂着‘Java 脚本语言’的名头，也吸引了很多注意力，对社区显然是有好处的。”

当然像这样的评价多少都会有点主观，而且情况会随着时间改变。比如最近受到 Sun 雇佣 Frank Wierzbicki 和 Ted Leung 的鼓舞，Jython 的活跃程度就在上升，他们未来应该会改善 Jython Web 框架的状况。无论如何 Jensen 的文章提供了一个很好的起点，也给面临类似决策的架构师和开发者们设立了一组基本的评估标准。

查看英文原文： JVM Dynamic Language Shootout