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
评论