Java and Linux - an open marriage in search of success
Two-years and counting
In 2004 Eric Raymond wrote an open letter to Sun Microsystems' then chief executive officer Scott McNealy demanding Sun open up their core Java intellectual property and allow anyone do whatever they damn well please with it.
That other pillar of open source, and creator of the GNU Project Richard Stallman, meanwhile, became one of Java's loudest opponents - sternly advising people not to install the closed-source evil that was Java, and giving Java as a dire example of corporate lock-in.
Sun also released Java Standard Edition (Java SE) for the desktop, Java Mobile Edition (Java ME) for mobile devices and Glassfish - Sun's implementation of Java Enterprise Edition (Java EE) - under GNU General Public License v2 (GPLv2). Sun said GPLv2 would achieve the objectives of "driving more volume and adoption for Java and maintaining the 'write once run anywhere compatibility' promise."
Sun has spent much of the intervening period talking about how OpenJDK would make it easier to distribute Java with Linux, putting Java into new markets and on platforms, and into the hands of new developers. Stallman, himself, was sufficiently impressed by the move.
Two years on, has Sun's move changed anything other than end the shouting war over whether to open-source Java?
Sun's chief open-source officer Simon Phipps told The Reg that OpenJDK is doing "at least as well as I hoped." Sun could hardly have done any worse.
But has the move improved the life of Joe the Programmer, the everyday coder? "If you're an everyday developer programming under Windows writing everyday programs, you'll probably see no visible differences. But a tools developer will see a huge difference, as their market has suddenly grown hugely," Phipps said.
In other words, their tools will now be easily available on Linux as well as Windows.
Java goes further
The addressable market is certainly bigger. OpenJDK is now included in the top four FOSS GNU Linux distributions - Fedora 10, the Ubuntu main repository starting with version 8.10, OpenSUSE 11, and the planned Lenny version of Debian. It's also available in Red Hat Enterprise Linux (RHEL5) and CentOS 5. Sun, meanwhile, claims success by download on Glassfish: eight million downloads and 250,000 "product registrations" in the last 12 months.
OK, so OpenJDK ships with top Linux distros - job done? Not quite. Java might ship with certain distros, but there is no single version of Java, or set of Java APIs or libraries, certified as 100-per-cent Linux compatible. That makes the job of installing it and administering Java on Linux a headache and creates portability hurdles for application developers writing software for different Linuxes.
Running a locked-down distribution in a bank? That's OK, until you need to install new APIs to run your particular application. Details of where and how to install Java can vary greatly from distribution to distribution and between different Java implementations. And with so many Java updates, the question next becomes which version do you install - the latest or most widely used?
Until now, Java has been supported by distros on a case-by-case basis through lobbying by Sun. It's lacked a single-industry wide impetus - something that could help standardize what you adopt, how it's installed and what you certify against.
That could change soon, though, as the Linux Foundation has announced the Linux Standard Base 4.0, due in "late" 2008", will work with Java SE 6.0. The LSB should at least ensure certified Linux distros and the applications on them work consistently with Java SE 6.0.
LSB 4.0 due to be supported by Asianux 3.0, Mandriva Corporate 5.0, RHEL 5.0, SLES Enterprise 10 and Ubuntu LTS 8.04, according to the Linux Foundation.
Underlying this, though, are two important facts. LSB 4.0 won't - as ever - be supported by all distros so consistent development and administration will remain a challenge.
Also, it's unlikely Java is ever going to be the "de facto" language of choice for Linux developers: they'll stick to their FOSS favorites. Take Glassfish: Sun's failed to prove where Glassfish is being used to change the market or challenge paid-for rivals. Indeed, there's already an established enterprise-edition tuned to a new, light-weight world that's doing very well nicely: it's called Spring.
Next, there's the test compatibility kit (TCK) issue. The TCK provides the compatibility yardstick to measure the Java Virtual Machine (JVM's) purity. Sun seems adamant that the TCK will never be opened: if it were, then it could be forked, then there would be much fear and chaos in this darkened world.
But then, isn't the freedom to choose to fork the whole point of open source? Detractors point out that while the move to put Java out there under the GPL appears to be more than mere lip service, beneath it all Sun hasn't really opened up anything. Sun still holds tight control over its intellectual property.
Then again, one wonders how much Sun would really be obligated to give away, to appease Stallman and the Slashdotters.
What I'm left with is a sense that opening up Java with GPLv2 was the right thing to do and was a shrewd move by Sun: but, while it may have silenced a few open-source zealots, two years later in purely practical terms it hasn't really achieved very much.
The one notable exception was that OpenJDK helped bring Java 6 SE to OS X and looks set to put it in the LSB.
Aside from that it's not clear whether we are really any further forward. You can now download a Java Runtime Environment (JRE) for your mum's favorite brand of Linux, but then you already could. You can now ship the JRE with your own product, but then Sun's licensing allowed that already.
Elsewhere, native Linux developers are as unlikely as ever to use Java to create new applications and if anyone sees fit to fork Java they'll have a hard job without an OpenTCK. As far as corporate programmers go, they may have read about OpenJDK in their lunch breaks but that's probably about as far as it goes for them. Not exactly deep impact.
Java is already king in the land where it matters - on the serverside - and Sun is still doing silly walks when it comes to client-side Java.
It seems that Sun being prepared to talk the talk about OpenJDK had a far greater effect than walking the walk. But for all of that, opening up Java was the right move, and I'm excited to see what inroads the OpenJDK will have made in another two years from now.®
Matt Stephens is co-author of Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to get from use cases to source code and tests, using Spring Framework, JUnit and Enterprise Architect.
Additional reporting by Gavin Clarke