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