Tracking change and innovation in the enterprise software development community
Create REST
-enabled Web Apps
with Project Zero
from IBM.
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Posted by Werner Schuster on Jul 27, 2007 09:00 AM
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.jruby filename.rb
java.util.concurrency classes. Introducing Project Zero: Building RESTful services for your Web application
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Introducing application infrastructure virtualization and WebSphere Virtual Enterprise
Spring App Platform, Java Concurrency/Multicore, Eclipse Mylyn and more @ QCon SF Nov 19-21
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
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: http://www.mail-archive.com/dev@struts.apache.org/msg21227.html 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. :)
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
14 comments
Reply