JRuby：该不该转向Java 5？

作者 Werner Schuster 译者 Jason Lai 发布于 2007年7月30日

领域

架构 & 设计,

运维 & 基础架构,

语言 & 开发

主题

Ruby ,

编程 ,

配置管理 ,

Java

标签

语言特性 ,

部署 ,

JRuby ,

Apache Harmony ,

开源Java

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

1. 返回顶部

   翻译的真不怎么样.

   发表人 wei Kent

   看文字很别扭.

   回复

• 更早的 >