Red Hat Joins Open Source Java Project 121
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."
parallel universe (Score:3, Insightful)
Re:mono (Score:2, Insightful)
I dunno. I chuckled. Mods, make your own decision.
Re:Other Linux Java Options? (Score:3, Insightful)
Re:Sun has found religion.. (Score:3, Insightful)
Re:Will anything change for end users? (Score:3, Insightful)
Only a few issues makes it harder to run all on the latest SUN JRE, and none of them are considered good programming practice. I suggest that you take that back to the app vendors and tell them to get it right and working on the latest released Java (1.6).
The major problem I have recognized is actually related more to the centrally distribution of software packages in a company network where an older JRE is installed and overrides the path of the latest JRE. That causes more problems than you deserve. Of course - in the end it depends on the installation software that thinks that since I'm last to be installed I'm the latest version, which is REALLY WRONG in many cases.
Re:Will anything change for end users? (Score:4, Insightful)
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.
Re:parallel universe (Score:1, Insightful)
So SUN gave Java on Linux a bad name by making its stuff harder to install than alternatives