JRuby:该不该转向 Java 5?

  • Werner Schuster
  • Jason lai

2007 年 7 月 30 日

话题:JavaRuby编程语言DevOps语言 & 开发架构

jruby-dev邮件列表中,一个关于向 Java 5 迁移的讨论已经展开。早在 Java 5 被引入之时,这就已经是对于 Java 项目频繁讨论的话题了。有许多项目,例如 Eclipse,选择尽可能久地保持对 1.4 的兼容性,甚至有一些基本技术,例如 OSGi 或者SWT 还在保持对 1.1 和 1.2 的兼容性

独立应用程序在这方面问题则少了很多,尤其在它们的发行版附带了 JVM 的情况下更是如此。而在另一方面,类库则像个烫手山芋,因为向 Java 5 的迁移,从根本上意味着被强制部署在 Java 1.4 环境下的类库使用者将无法使用该类库,或者他们必须使用类库能够支持 Java 5 的较新版本。

JRuby 则处在独立应用程序和类库之间。毕竟,人们可以使用下面的一行命令来运行任意的 Ruby 程序:

jruby filename.rb

对于这种情况,JRuby 需要某个特殊的 Java 版本并不会成为问题,除非 JRuby 中的特定代码需要 Java 5 类库。当然,如果公司在某个 Java 版本上进行了标准化的话,那么这就会成为一个问题了。

当 JRuby 被用在应用程序内部作为 Ruby 解析器的时候,它的身份也就变成了一个类库。在这种情况下,如果提高了 JRuby 所需的 Java 版本,也将迫使宿主应用不得不升级相应的需求(如果这些应用还没有使用 Java 5)。

除了允许 JRuby 团队使用诸如Annotation或者Enum这样的新语言特性以外,人们对打破与 1.4 的兼容性以及使用 Java 5 的新特性方面,还有一些相当有力的支持论据。其中之一就是在 Java 5 新增的高级并发类库。目前,JRuby 的分发包中还附带了用于早期 Java 版本的java.util.concurrent移植版类库,这就意味着下载大小的增加。此外,由于这个移植版无法使用 Java 5 中针对并发支持的类,它其中的某些功能无法和 Java 5 的java.util.concurrent系列类相匹敌的性能。

保持 1.4 版本兼容性的主要原因是大公司的升级周期一般都非常长,因此他们会试图在软件版本上进行标准化。然而,由于绝大多数平台都提供了 Java 5 的支持,当然也就是 Windows、MacOS X 和 Linux 的三重唱,因此反对向 Java 5 迁移的理由已经很快变得非常微不足道了。在 Java 5 发布了三年之后,有了早期采用者发现并报告问题之后,JVM 及其类库也已经可以很安全地被认为是成熟了的。

另外一个原因相比起来就不是那么重要了,即缺乏一个基于自由(文如其名)软件许可,与 Java 5 完全兼容的实现。尽管GNU Classpath以及Apache Harmony项目正在一步一步朝着完全兼容的目标挪进,但它们都还不到火候。实现 95% 以上的 API 完成度,已经是这些项目所取得的极大成功,但比起和 Java 5 100% 兼容的目标,还仍显不足。尽管类似于 Eclipse 这样的大型应用可以运行在开源 JVM 之上,但仍有一些小的不兼容问题会随时跳将出来,也可能成为支持部门头上的一道金箍。

随着 Sun 公司 OpenJDK 项目的产生,一个完全以 GPL 授权的 Java 将会在不久的将来问世。(注意,Java 的其中一些部分还没有以 GPL 的形式授权,因为 Sun 还不具备将这些部分用 GPL 授权的权力)。

应该提到的是,已经发布的 JRuby 1.0 是兼容于 Java 1.4 的,并且也将一如既往保持对 1.4 的支持。

对此您又是什么样的想法呢?您是否还在从事需要保持 1.4 兼容性项目的开发呢?如果是的话,在公司标准之外是否还有其它原因呢?

查看英文原文:JRuby: Java5 or not?

JavaRuby编程语言DevOps语言 & 开发架构