New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
JRuby: Java5 or not?
Posted by Werner Schuster on Jul 27, 2007
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?
RelatedVendorContent
Five Key Practices to Agile ALM
A Guide to Branching and Merging Patterns
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
-
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 -
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! -
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. -
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.
-
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. -
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 -
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. -
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 -
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). -
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. -
@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. -
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. -
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. -
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. :)
14 comments
Watch Thread Reply