JRuby: Java5 or not?

Posted by Werner Schuster on Jul 27, 2007 09:00 AM

Community

Java,

Ruby

Topics

Programming ,

Configuration Management

Tags

Open source Java ,

JRuby ,

Apache Harmony ,

Deployment ,

Language Features

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:

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?

1. Back to top

   Go for it!

   Jul 27, 2007 11:38 AM by James Strachan

   I'd say go right ahead. If folks wanna run Java 5 on Java 1.4 you can always use the excellent retrotranslator... http://retrotranslator.sourceforge.net/ which can even be enabled via the JIT (so its kinda invisible to the end user)... http://retrotranslator.sourceforge.net/#jit James Iona Open Source the Enterprise Way

   Reply

2. Back to top

   Please move to Java 5, please!!!

   Jul 27, 2007 2:29 PM by Tim O'Brien

   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!

   Reply

3. Back to top

   Re: Please move to Java 5, please!!!

   Jul 27, 2007 4:14 PM by Michael Neale

   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.

   Reply

4. Back to top

   Do it right from the start

   Jul 27, 2007 4:43 PM by Johann Petrak

   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.

   Reply

5. Back to top

   Re: Please move to Java 5, please!!!

   Jul 27, 2007 4:51 PM by Werner Schuster

   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.

   Reply

6. Back to top

   Re: Go for it!

   Jul 28, 2007 4:49 AM by Alex Popescu

   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

   Reply

7. Back to top

   What about J2ME?

   Jul 28, 2007 7:40 PM by Neil Bartlett

   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.

   Reply

8. Back to top

   Re: What about J2ME?

   Jul 29, 2007 3:19 AM by Alex Popescu

   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.

   ... and since April BEA: JRockit for Java SE 6 is GA. ./alex -- .w( the_mindstorm )p. ________________________ Alexandru Popescu Senior Software Eng. InfoQ TechLead&CoFounder

   Reply

9. Back to top

   Re: What about J2ME?

   Jul 29, 2007 2:47 PM by Werner Schuster

   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).

   Reply

10. Back to top

    Re: What about J2ME?

    Jul 29, 2007 6:09 PM by Don Brown

    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).

    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.

    Reply

11. Back to top

    Re: What about J2ME?

    Jul 30, 2007 9:00 AM by Werner Schuster

    @Don Brown: Interesting, seems like retrotranslator emulates quite a lot. There are limits: http://www.mail-archive.com/dev@struts.apache.org/msg21227.html but I guess that's fine for this case.

    Reply

12. Back to top

    Re: What about J2ME?

    Jul 30, 2007 12:06 PM by Daniel Berger

    I agree with the prevailing sentiment about moving to Java The only JVM vendor supporting Java 6 at the moment is Sun, which means it only runs on Windows, Linux and Solaris.

    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.

    Reply

13. Back to top

    Re: What about J2ME?

    Aug 1, 2007 8:31 AM by Neil Bartlett

    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.

    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.

    Reply

14. Back to top

    Re: What about J2ME?

    Aug 1, 2007 1:13 PM by Daniel Berger

    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. :)

    Reply

• Older >