IBM Ditches Apache Harmony Java for Oracle OpenJDK

October 18, 2010 Timothy Prickett Morgan

Let’s get one thing straight. Well, two things, actually. One, it was a colossal blunder on the part of IBM and all of its software aspirations to have let the Java programming language and runtime fall into the hands of rival Oracle in the application development and database spaces. And two, no matter how much love Oracle professes for hardware and the Solaris operating system, the main reason that the software giant ponied up $5.6 billion net of Sun Microsystems cash on hand to acquire the beleaguered server makers was to get absolute control–or what passes for it in a pseudo-open Java Community Process–of Java.

IBM’s lack of control of Java means that it has to cope with a haughty Oracle, which read the Java community the riot act about its plans for Java a month ago at the OpenWorld-JavaOne extravaganza in San Francisco and then promptly sued Google for distributing a variant of Java on its Android phones that doesn’t meet the guidelines that Sun and now Oracle have set.

Let’s talk about the Google suit first, then how Oracle and IBM came to be allies after some contention about implementations of the Java stack in the wake of the Oracle Java roadmap and the Google suit.

Oracle sued Google in mid-August, saying that the Android operating system for smart phones (and soon netbooks) infringes patents and copyrights for Java held by Oracle in the wake of the Sun acquisition. The basic problem is that the write-once-run-many-times promise of Java is, well, to use a technical term, horsehockey. There are Java Standard Edition, Java Enterprise Edition, and Java Mobile Edition for handhelds and other tiny computers, and code written for one doesn’t run on the others because features in the Java language and the runtime are not the same across all three. And this is necessarily so, some would argue. A server has to do different things from a desktop, after all. The Java FX extensions to the programming language were supposed to span the SE and ME editions, to make applications portable.

The problem Oracle has with Google is that the search giant grabbed the Project Harmony implementation of the Java SE stack–which is controlled by the Apache Software Foundation IBM backed originally and used to gain leverage with Sun–and made its own tweaks to it to embed Java capabilities into the Android handset operating system. This virtual machine, called Dalvik, does not use the sanctified Java FX Mobile tools, but tweaks the desktop code so it run on handsets and goes even further by having a different set of interfaces into the Java development kit (not Swing or AWT, which are authorized).

Pandemonium, that’s what that is as far as Oracle is concerned. And it is also an excuse for Oracle to flex its muscle in the industry, to show who really has control over what Java is and what it isn’t, and to put itself in the role of champion of the Java standard. Oracle could not wait to sue Google. Or, for that matter, IBM if it pushed the Project Harmony implementation of Java SE too far.

Well, you can forget that. Last week, Bob Sutor, vice president of open systems and Linux at IBM, blogged that IBM was throwing away the Project Harmony lever that has gotten Google into trouble and is now backing the OpenJDK project, which is an open source implementation of Java SE that Sun put out under the GNU General Public License back in 2006. Harmony was an unofficial, uncertified, and equally open source Java implementation, and given its lack of Sun’s and now Oracle’s blessing, Sutor says that IBM has decided to “reverse fork” and back the official OpenJDK. In other words, IBM doesn’t want to be sued next.

The OpenJDK kit is based on the former Sun’s HotSpot Java virtual machine runtime, but will likely see some features from the JRockit JVM that Oracle acquired when it bought Web application server maker WebLogic a few years back.

How this pushing and shoving over Java SE affects IBM i shops remains unclear. In IBM i 6.1, Big Blue used implementations of JDK 1.4. JDK 5, and JDK 6 from Sun for the “classic” 64-bit, embedded JVMs for the operating system and used Java 2 SE 5 and Java SE 6 as the basis of the 32-bit and 64-bit AIX-ish JVMs that are now the preferred JVMs on the box. The classic JVMs were not perfectly compatible with the Java SE standard, which caused application compatibility problems even if they did offer performance benefits specifically for OS/400-ish platforms. (The same thing that Google is doing, at least in principle, with Android.) With i 7.1, as we previously reported, IBM dropped the classic JVM cooked up by the Rochester labs, and in hindsight, this perhaps had more to do with potential legal issues than actual technical ones.

What is clear at this point is that IBM had to join the OpenJDK effort to have any effect on the future of Java. But how much leverage compared to Oracle, which has a huge application, middleware, and database business based on Java, is debatable. Oracle is using the OpenJDK to freeze out the Java Community Process (JCP), the Byzantine community that has controlled Java up until now. Oracle did much the same with the OpenSolaris community that was created to turn Solaris from a closed source Unix into a Linux-alike platform (in terms of development model and free distribution of source and binaries).

According to the latest Oracle OpenJDK roadmaps, Java SE will see a JDK 7 release (which has been much delayed) in 2011 and a follow-on JDK 8 in 2012. Oracle is in the process of merging the HotSpot and JRockit JVMs, taking the best bits for each and crafting JVMs tuned for desktops and servers. The resulting merged JVM will be contributed to the OpenJDK community, and will presumably be the basis of the future JVMs used in IBM i 8 or 9. You can get a list of the proposed features for the future JDK’s here. Java EE is still going to get some work to make application servers more modular, but this has no impact on the IBM i platform unless IBM decides to embed Java EE in the operating system. This seems highly unlikely.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search