在 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 版本的 <strong>java.util.concurrent</strong>
移植版类库,这就意味着下载大小的增加。此外,由于这个移植版无法使用 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?
评论