Open-source Java and compatibility in the Java world

Sun is worried about compatibility in a world where Java is open source. I can’t say I blame them, and I say this as someone who spends a majority of his time thinking about compatibility in the Linux world, where we’ve managed to hold it together but still have a lot of work to do to match the relative consistency of the Microsoft alternatives (Windows and .NET, among others). After all, a platform is useless if there’s not a single, standard way for developers to target it.

Question is: Does open source inherently lead to compatibility problems? Hardly. How many incompatible versions of, say, Apache are there? Or the Ps of the LAMP stack (Perl, PHP, Python)? Or MySQL? GNOME? KDE? BIND? CUPS? The only reason “Linux” and compatibility often come up in the same breath is because the term is used to describe so many different things. Yes, “Linux” has compatibility issues if you’re comparing Red Hat, SUSE, and Debian, but the actual “Linux” used by each of these “Linuxes” (that is, the Linux kernel) have few if any compatibility issues. It’s more the bits around the edges, like slightly different versions of core components with slightly different ABIs or APIs, not to mention the independently developed subsystems for configuration etc., that lead to the compatibility issues. If anything, the fact that the various Linux distributions share so many of the same open source components makes them far more compatible than the various implementations of UNIX ever were.

James Gosling, the father of Java, highlights JavaScript as an example of the situation they’re trying to avoid in a recent podcast with Dan Farber. Today, he explains, there are dozens of AJAX toolkits, and the main reason for this is the need to paper over incompatibilities between the various JavaScript implementations.

He’s absolutely right. If anything, though, the JavaScript situation is a good example of what might have been if we knew as much about the power of open source in setting standards in the 1990s as we know today. There are numerous JavaScript implementations today because there wasn’t a de facto standard implementation developers could just use when they needed one way back when (like there was with Apache etc. and wasn’t with some of the problematic “Linux” technologies like configuration management). What if there had been an open source JavaScript all along that became a de facto standard like Apache did? Would the AJAX world look any different today?

Ironically, then, Java looks a whole lot more fragmented on its current trajectory as the various open source efforts (Apache Harmony, GCJ, GNU Classpath, etc.)—which exist only because the de facto standard implementation isn’t open source—mature and are more tightly integrated into the Linux distributions.

So, what lessons does Linux have to offer Sun as it contemplates the future of Java and, more to the point, how to open source it? First of all, far from being a surefire path to turning Java into a veritable tower of babel, open source could actually help promote compatibility in the Java world. For one thing, if Sun’s Java implementation was open source, history shows there would be no need for another implementation. Case in point: Remember the other Harmony project?

Secondly, what’s in a name? Absolutely everything. It’s entirely possible to open source Java without diluting the Java brand and the compatibility guarantees that brand promises. Most famously, this strategy has worked very well for Red Hat—Red Hat’s platform is open source, so you can fork it, but you can’t call the result “Red Hat”, which preserves the compatibility guarantee a successful platform requires.

It’s not too late, but we’re rapidly approaching a time when it will be. For one thing, the open source implementations are getting better, and once the genie is out of the bottle, it’s damned near impossible to get it back in (see, again, JavaScript). As I said the other day, “open source Java” isn’t so much about licensing as it is about ubiquity, though licensing can get in the way of ubiquity. We’re almost there. Let’s take the final step we need to take to make Linux/Java as well integrated as Windows/.NET.

4 Responses to “Open-source Java and compatibility in the Java world”

  1. Alex says:

    Your example of PHP is not great; it can be horrendously incompatible even over minor revisions. If Java were developed along the same lines, it would ruin what Java is supposed to be.

    I think the “open source” thing is a red herring in a way though – PHP would be as badly incompatible if it were non-free. It’s about software design.

  2. Ian Murdock says:

    Fair enough. I was speaking more of incompatible versions maintained by independent groups (i.e., forks). Not all open-source projects (and, as you point out, non-open-source projects) are created equal when it comes to software engineering discipline. -ian

  3. Steve Parker says:

    RedHat have suffered some very bad PR from their “Yes we’re open-source but you’ve got to rebuild most of our packages into CentOS/WhiteBox if you want to redistribute our code” attitude, and lost a lot of the (good) credibility which they had built up in the community over the years.

    Despite buying and open-sourcing StarOffice->OpenOffice.org, etc, Sun are still seen (by the slashdot crowd, at least) as not terribly F/OSS-friendly; RedHat just about survived the slashdot mauling because of their previously good reputation. I can easily see that the Sun execs would predict the vocal elements of the community taking the view that Sun were “pretending” to open-source Java if they still insisted on retaining the same hold over the “Brand” as before.

    A simpler (or at least interim) solution is just to certify a given VM as JRE-Compatible based upon its functionality, but hey, I’m just some simplistic fool ;-)

  4. SunMink says:

    Grokking Compatibility

    One of the strong notes at JavaOne last week was hearing Jonathan Schwartz and Rich Green underlining that compatibility is key to open sourcing Sun’s implementation of Java SE (from which the reference implementation is derived, and which is the so…

Additional comments powered by BackType