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?
Community comments
Go for it!
by James Strachan,
Re: Go for it!
by Alex Popescu,
Please move to Java 5, please!!!
by Tim O'Brien,
Re: Please move to Java 5, please!!!
by Michael Neale,
Re: Please move to Java 5, please!!!
by Werner Schuster,
Do it right from the start
by Johann Petrak,
What about J2ME?
by Neil Bartlett,
Re: What about J2ME?
by Alex Popescu,
Re: What about J2ME?
by Werner Schuster,
Re: What about J2ME?
by Don Brown,
Re: What about J2ME?
by Werner Schuster,
Re: What about J2ME?
by Daniel Berger,
Re: What about J2ME?
by Neil Bartlett,
Re: What about J2ME?
by Daniel Berger,
Go for it!
by James Strachan,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'd say go right ahead. If folks wanna run Java 5 on Java 1.4 you can always use the excellent retrotranslator...
retrotranslator.sourceforge.net/
which can even be enabled via the JIT (so its kinda invisible to the end user)...
retrotranslator.sourceforge.net/#jit
James
Iona
Open Source the Enterprise Way
Please move to Java 5, please!!!
by Tim O'Brien,
Your message is awaiting moderation. Thank you for participating in the discussion.
Backwards compatibility for a project this new seems like wasted effort and energy. People looking at JRuby are not looking at integrating some legacy application that runs on 1.4 to JRuby, they are looking at using JRuby in new development.
Echoing James' sentiments: Go for it!
Re: Please move to Java 5, please!!!
by Michael Neale,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree. If an organisation is still stuck on 1.4 for pragmatic reasons, then they aren't the sort of organisation that would take on JRuby.
If it helps, they should make the jump to java 6, but I am not sure if it offers anything that can't be made available in 5.
Do it right from the start
by Johann Petrak,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is new enough to take the liberty and make it right from the start. Go for Java 5 or even Java 6 if necessary. It will pay off manyfold in the future.
Re: Please move to Java 5, please!!!
by Werner Schuster,
Your message is awaiting moderation. Thank you for participating in the discussion.
I guess moving to Java 6 would annoy the Apple users - as far as I know there's still no public Java 6 for MacOS X (besides the one Developer Connection).
Targeting Java 6 would allow to preverify all classes, which should allow for faster class loading on Java 6 JVMs - although I'm not sure if that would give them massive speed ups.
Re: Go for it!
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
IMO James and all are very right about it, and JRuby team should be extremely happy to be in this position. Unfortunately, the same doesn't apply for Groovy where integration with older solutions is one of its selling points.
bests,
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
What about J2ME?
by Neil Bartlett,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with the prevailing sentiment about moving to Java 5, as long as we are only considering desktop (J2SE) uses of JRuby. But what about mobile devices? The state of the art there is Java 1.4, and full Java 5 support even on the more capable mobile devices such as palmtops and smartphones is still a way off.
However, I don't know if anybody actually cares about JRuby on mobile devices. Developers for those platforms are certainly accustomed to making do with less-than-optimal tools and languages.
Anyway, please PLEASE don't even think about Java 6. The only JVM vendor supporting Java 6 at the moment is Sun, which means it only runs on Windows, Linux and Solaris.
Re: What about J2ME?
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
... and since April BEA: JRockit for Java SE 6 is GA.
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
Re: What about J2ME?
by Werner Schuster,
Your message is awaiting moderation. Thank you for participating in the discussion.
I remember seeing a mention of JRuby on J2ME on the jruby-dev list, but I believe it requires a serious amount of hackery. Also, keep in mind that the jruby.jar alone is 2+ MB, and from what I understand, that's without some necessary libs such as ASM, BSF, the concurrency backport, etc.
The move to Java 5 would finally kick the possibility for JRuby to run on current J2ME implementations - in my point of view. Once the team'll start using things like Annotations or simply 1.5 APIs, there's not much chance of using retroweaver (or whatever it's called toady).
Re: What about J2ME?
by Don Brown,
Your message is awaiting moderation. Thank you for participating in the discussion.
Actually, that's not correct. Retrotranslator, an alternate library, can handle most Java 5 API's, varargs, generics, and even annotations. Struts 2, among other Java 5 libraries including Stripes, has been using it for over a year now successfully.
Re: What about J2ME?
by Werner Schuster,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Don Brown:
Interesting, seems like retrotranslator emulates quite a lot. There are limits:
www.mail-archive.com/dev@struts.apache.org/msg2...
but I guess that's fine for this case.
Re: What about J2ME?
by Daniel Berger,
Your message is awaiting moderation. Thank you for participating in the discussion.
You mean, it only runs on a mere 90% of the platforms that people actually deploy on? In that case, I vote for Java 6 if there are significant benefits.
Re: What about J2ME?
by Neil Bartlett,
Your message is awaiting moderation. Thank you for participating in the discussion.
Two points in response to this. Firstly the percentage of developers using Macs is higher than the percentage of general computer owners using Macs, i.e. it is significantly higher than 10%. Therefore moving to a platform which (currently) excludes that platform would be very damaging. Of course you can rail against Apple for failing to update their JVM, but that would be pointless. The fact remains that tying a product to Java 6 would kill it for a very popular Java development platform.
Secondly, Java 6 was an incremental change, compared with the upheaval of Java 5. It would be difficult to even find Java-6-only APIs for JRuby to depend on! So remaining at Java 5 compatibility shouldn't be any kind of hardship whatsoever.
Re: What about J2ME?
by Daniel Berger,
Your message is awaiting moderation. Thank you for participating in the discussion.
Neil,
Deployment != Development. :)
But, I wasn't aware that Java 6 was only an incremental change. If that's so (and I'll take your word for it that it is), then Java 5 is good enough. :)