JRuby: Java5 or not?

by Werner Schuster on Jul 27, 2007 |

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?

Related Editorial

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Making the Shift from Relational to NoSQL

Extend Your Java EE Apps with a Mobile Web Interface

Beyond HTML5 and Native Development: Build Richer, More Functional Mobile Applications

Infographic: Just How Big is the Nerd Economy

Related Sponsor

Get code level visibility into your web apps. All for free.

Try New Relic Today.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Go for it! by James Strachan Posted

Re: Go for it! by Alex Popescu Posted

Please move to Java 5, please!!! by Tim O'Brien Posted

Re: Please move to Java 5, please!!! by Michael Neale Posted

Re: Please move to Java 5, please!!! by Werner Schuster Posted

Do it right from the start by Johann Petrak Posted

What about J2ME? by Neil Bartlett Posted

Re: What about J2ME? by Alex Popescu Posted

Re: What about J2ME? by Werner Schuster Posted

Re: What about J2ME? by Don Brown Posted

Re: What about J2ME? by Werner Schuster Posted

Re: What about J2ME? by Daniel Berger Posted

Re: What about J2ME? by Neil Bartlett Posted

Re: What about J2ME? by Daniel Berger Posted

Go for it! 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...
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

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

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

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

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

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

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

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

Re: What about J2ME? 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).

Re: What about J2ME? 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.

Re: What about J2ME? by Werner Schuster

@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

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.

Re: What about J2ME? 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.

Re: What about J2ME? 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. :)