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的文章提供了一个很好的起点，也给面临类似决策的架构师和开发者们设立了一组基本的评估标准。

TAG:
JVM