On the jruby-dev list, a discussion about moving to Java 5 was kicked off. This is a frequent topic for Java projects ever since Java 5 was introduced. Many projects, like Eclipse, opted to staying 1.4 compatible as long as possible, with basic technologies and libraries like OSGi or SWT even staying 1.1 or 1.2 compatible.
Standalone applications are less of an issue, particularly if they ship the JVM they need. Libraries, on the other hand, are problematic, since the move to Java 5 basically means that library clients forced to deploy to Java 1.4 can't use the library, or at least newer versions that require Java 5.
JRuby is somewhere in between standalone application and library. After all, it's possible to just run any Ruby program using:
For this, JRuby requiring a particular Java version is not a problem, unless it's JRuby specific code that needs Java 5 libraries. Of course, if a company has standardized on a particular Java version, then this becomes an issue.
JRuby is also in the position of a library, when it's used as an embedded Ruby interpreter inside an application. For that, raising the required Java version number, will force the embedding applications to upgrade their requirements (if they don't already use Java 5).
There are good arguments for breaking compatibility with 1.4 and using Java 5 features, besides allowing the JRuby team to use the new language features like Annotations or Enums. One would be the advanced concurrency libraries which were added to Java 5. Right now, a backport of the java.util.concurrent libraries is shipped with JRuby, which means increased download size. Also, since this backport can't make use of Java 5 specific classes for concurrency support, some functionality won't run with the same performance as with the Java 5
A big reason for keeping 1.4 compatibility is the long upgrade cycles of large companies, which try to standardize on software versions. However, the reasons against a move to Java 5 are dwindling fast, as most platforms have Java 5 support, certainly the main trio of Windows, MacOS X, and Linux. Three years after the Java 5 release, the JVMs and libraries can also safely be assumed to be mature, with issues found and reported by early adopters.
Another, albeit increasingly less significant reason, is the lack of a fully compatible Java 5 implementation under a free (as in "speech") license. While GNU Classpath as well as the Apache Harmony project are inching closer to the goal of full compatibility, they're just not quite there yet. API completeness upwards of 95 % is a great achievement for these projects, but it's still less than 100% Java 5 compatibility. While big applications like Eclipse run on free JVMs, small incompatibilities can still surface, potentially causing headaches for support departments.
With the OpenJDK project by Sun, a full Java under the GPL should be available at some near point in the future. (Note that a few parts of Java are not yet available under the GPL, because Sun doesn't have the rights to publish them under this license ).
It must be mentioned that the released JRuby 1.0 is compatible with Java 1.4, and will remain that way. The move is discussed for future JRuby versions.
What is your opinion? Do you work on a project that still needs to maintain 1.4 compatibility? If yes, are there reasons besides company standards?
Standalone applications are less of an issue, particularly if they ship the JVM they need. Libraries, on the other hand, are problematic, since the move to Java 5 basically means that library clients forced to deploy to Java 1.4 can't use the library, or at least newer versions that require Java 5.
JRuby is somewhere in between standalone application and library. After all, it's possible to just run any Ruby program using:
jruby filename.rb
For this, JRuby requiring a particular Java version is not a problem, unless it's JRuby specific code that needs Java 5 libraries. Of course, if a company has standardized on a particular Java version, then this becomes an issue.
JRuby is also in the position of a library, when it's used as an embedded Ruby interpreter inside an application. For that, raising the required Java version number, will force the embedding applications to upgrade their requirements (if they don't already use Java 5).
There are good arguments for breaking compatibility with 1.4 and using Java 5 features, besides allowing the JRuby team to use the new language features like Annotations or Enums. One would be the advanced concurrency libraries which were added to Java 5. Right now, a backport of the java.util.concurrent libraries is shipped with JRuby, which means increased download size. Also, since this backport can't make use of Java 5 specific classes for concurrency support, some functionality won't run with the same performance as with the Java 5
java.util.concurrency classes. A big reason for keeping 1.4 compatibility is the long upgrade cycles of large companies, which try to standardize on software versions. However, the reasons against a move to Java 5 are dwindling fast, as most platforms have Java 5 support, certainly the main trio of Windows, MacOS X, and Linux. Three years after the Java 5 release, the JVMs and libraries can also safely be assumed to be mature, with issues found and reported by early adopters.
Another, albeit increasingly less significant reason, is the lack of a fully compatible Java 5 implementation under a free (as in "speech") license. While GNU Classpath as well as the Apache Harmony project are inching closer to the goal of full compatibility, they're just not quite there yet. API completeness upwards of 95 % is a great achievement for these projects, but it's still less than 100% Java 5 compatibility. While big applications like Eclipse run on free JVMs, small incompatibilities can still surface, potentially causing headaches for support departments.
With the OpenJDK project by Sun, a full Java under the GPL should be available at some near point in the future. (Note that a few parts of Java are not yet available under the GPL, because Sun doesn't have the rights to publish them under this license ).
It must be mentioned that the released JRuby 1.0 is compatible with Java 1.4, and will remain that way. The move is discussed for future JRuby versions.
What is your opinion? Do you work on a project that still needs to maintain 1.4 compatibility? If yes, are there reasons besides company standards?