Red Hat Joins Open Source Java Project

narramissic writes "Red Hat has signed on to Sun's OpenJDK project and agreed to coordinate its own Java development efforts for Linux with the project. Red Hat will align the work it has done on IcedTea (its own implementation of some parts of the Java SE JDK) with OpenJDK. As part of its participation in OpenJDK, Red Hat will eventually create a compatible OpenJDK implementation for its Enterprise Linux distribution and will also use OpenJDK to create a runtime for its JBoss Enterprise Middleware that is optimized for a Linux environment."

Comments

Re:Sun has found religion..

[publicworker]

Sun, you might win over my heart just yet.

I don't think they care about your heart. It's your wallet they are going after. For most geeks the way to their wallet is via their heart.

Re:Will anything change for end users?

[hey!]

I think the biggest problem with the original write once, run everywhere promise was this: Java was almost, but not quite, an operating system. If you had a system that worked on WinXP but not Vista, you'd fix the problem; you wouldn't tell your customers to install both operating systems on the same machine because he can't. If I had A,B and C that only ran on Windows versions X,Y and Z respectively, I'd take the trouble to make A and B run on Z.

In Java I can get by with A, B and C each running only on JDK 1.2, 1.4 and 1.6 respectively, but I have to call upon the user, working with the host OS, to deal with any confusion that arises. Now, multiply that by any libraries you use that aren't part of the standard java distribution, and things start to get really interesting.

In part the problem of Java classpaths is one of an embarrassment of riches. There are so many powerful frameworks and amazingly useful little libraries that are out there, free for the taking. However, once you open that Pandora's box, it isn't simply a matter of write once, run everywhere; you have to deal wit the dependency issues that come out of that box. It can be done, and it's not really all that difficult, it's just one of those craft things that some people seem to have figured out how to do and others seem to leave as an afterthought after all the fun stuff has been finished.

The embarrassment of riches also applies to the biggest pitfall in Java development: making bad framework choices, which you can do in multiples at the same time on any project. Leaving aside the case where you have a bad framework (the early EJB stuff -- ugh), or where you have made a bad mistake in requirements analysis, there are so many frameworks that are wonderful for one set of requirements and dreadful overkill for others. Working with a set less than optimally chosen frameworks sucks the joy out of a project, as you set aside the pleasure of solving the client's problem for the tedious drudgery of gluing together mismatched bits of architecture.