posted by Andy Roberts on Thu 9th Jun 2005 20:58 UTC
IconThe recent announcement from Apache regarding their plans to embark on their own J2SE implementation called Harmony has re-ignited the long-running Java/OSS debate. James "Father of Java" Gosling reacted in an unexpected way by giving a misleading view of what open source is really all about. Now that the dust has settled a little bit, it's time for an article that is not championing the cause for the relicensing of Sun's implementation under more permissive, open source terms, but simply a look at what could (and could not) happen under the open source model.

Whilst obviously aiming to be as objective as possible, I think it fair to let you know my leanings. I'm a big OSS fan. I've been using various forms of the GNU/Linux platform for around 8 years. I'm not a purist though: I will use propriety products if it does the job. Proof of this is that I am also a big Java fan. I started learning it around 5 years ago, although it's the last 3 years or so that it's been my main language. I honestly don't have an issue with the Java team, or Sun in general about their decisions. I don't always agree with their approach, specifically their licenses, but I don't mean to be anti-Sun, even if it should appear that way in this article (just anti-FUD).

The charges

In an interview with DevX, Gosling made some comments, which, to anyone already sceptical or ignorant of OSS, give a completely false impression.

"It's often difficult to get a good picture from the open source community of what they actually object to in what we're doing. In what way could we be more open? Since day zero, 10 years ago, all of our sources have been open and available, very similar to how many projects in open source work."

Later, he adds,

"We've got several thousand man-years of engineering in [Java], and we hear very strongly that if this thing turned into an open source project - where just any old person could check in stuff - they'd all freak. They'd all go screaming into the hills."
And in a subsequent interview on Vnunet:
"I understand why [the OSS community] would like it to be different. From our point of view that would actually be more destructive than helpful. It boils down to forking: they believe that the ability to fork is an absolutely critical right."

Let's be clear here - these are Gosling's opinions, not those necessarily of Sun. Gosling and Stallman famously had a fracas over Emacs which became the impetus for the GPL, so perhaps it's not so strange that Gosling has anti-OSS sentiments, and that Stallman has all guns blazing at Java. However, I've seen them echoed within various quarters of the Java community itself, and so it's a worthwhile cause to have a closer look, I think.

Who wants a free cup of coffee?

From an ideological perspective, Richard Stallman is clearly at the front of the queue here! Free to see the source code; free to modify the source code; free to redistribute the code. It's a freedom of speech thing really! OSS isn't necessarily about giving products away for free (i.e., without payment). You can still charge for it, but your source will be visible to the end-user (should they care to look). The Java platform is free as in beer, i.e., you don't have to pay. You can look at the source. You can modify and recompile. You can't freely redistribute modified Sun code. Tut tut: hell hath no fury like a RMS scorned...

From my experience, people don't like open source software because they can exercise the freedom of hacking with source code. They like it because it tends to deliver stable products; because it innovates; because it responds quickly to bugs and security issues; because it does the boring stuff that no-one else wants to do!

I've been fortunate to have an excellent contact regarding the Java/OSS issue in the shape of Dalibor Topic. He's unashamedly pro-free software and is the lead developer of Kaffe, contributor to GNU Classpath and Harmony participant. A tad biased one expects, but he always delivers decent explanations of the current situation - starting with Apache's motives,

"Apache Software Foundation, an organisation that's been quite successful at writing, maintaining and encouraging donations of Free Software written in the Java programming language eventually started thinking that a full J2SE implementation might be a good thing to have under Apache's umbrella as well, beside a huge chunk of the stack above it."

I couldn't agree more! The ASF have released some fantastic Java libraries that add tremendous value to the platform. Think about Ant, Log4j, Lucene, Struts, all the XML projects, and then there's Jakarta: Commons, POI, Tomcat, Velocity, Tapestry and so on. It's not just ASF who want an open J2SE to complete their stack, there is the wider free software community who need it. Dalibor notes:

"These days, there is an almost full Free Software stack, going from the Linux kernel, to the supporting GNU libraries from one side, and going from certified, compatible enterprise software development and deployment environments and their supporting libraries from the other side, like JBoss or JOnAS. The only remaining non-free card in that software stack is a fully compatible Free Software runtime for programs and libraries written in the Java programming language."
But I just made you a cuppa

There even seems to be some dissent within the OSS community itself. This is because OSS is itself a broad term and encapsulates a whole spectrum of ideologies. You don't have to look far before you find a complaints that Apache appear to be duplicating the efforts of GNU Classpath and VMs like Kaffe or GCJ. This isn't the case. The Harmony team want to reuse as much of the pre-existing components as possible (you would be foolish not to!) The issue is that there is a slight conflict between the GPL license and the Apache license. The difference essentially boils down to the fact that redistributed GPL code must preserve the GPL license (and thus remain Free) where as Apache lets you redistribute under your own license. But, Classpath has an 'exception' clause similar to that found in libgcc/libg++ which permits linkage in binary form under your own license. This means that Harmony could work by having Classpath as a binary dependency, thereby avoiding the reimplementation of the class libraries. Likewise there's already talk of using JCVM as a base for the VM. So, reuse is clearly on the agenda and Harmony is seeking all Apache friendly resources to evaluate their potential. Any shortcomings will of course have to be met by the Harmony developers and may require implementation of that component from scratch.

Forkin' hell

The biggest argument for resisting the opening of Java is that it permits forks of the platform that would lead to incompatible versions all competing against each other. The idea that all open source advocates want to do is fork everything is a slight exaggeration. Still, this is a very real concern that should be considered carefully. The example given is to think about all the hassle you have making sure your web page looks correct on all the mainstream browsers. Even closer to home was the controversy of Microsoft's non-standard JVM.

I personally don't think there will be many instances of a fully forked Java platform. It's pretty darn big! And I don't think any one wants to see a fragmented platform. What I think would happen is what I call 'micro-forks': stripped down versions that are designed for specific purposes. I also imagine you'd see the JVM ported to several other platforms that are not on Sun's radar at the moment. Dalibor speaks of Kaffe's success on reaching new platforms:

"Kaffe is one of the most widely ported pieces of runtime software around. In total, it has been ported to more than 70 platforms, ranging from good old x86 GNU/Linux to WindowsCE and PlayStation 2. There is a lot of interest on niche platforms in having ready access to Free Software written in the Java programming language, in particular if the platform in question does not have enough marketing value for some large corporation to step in and fund the porting and certification effort of a non-free runtime."

Sun already has a method to ensure the fragmentation of Java is avoided with it's JCK compatibility test suite. Since anyone is free to write their own Java compiler or runtime, Sun wanted a system that gives you the seal of approval, in that your implementation conforms to the specifications. It contains comprehensive testing of all aspects of the platform and at last count the number of tests it contained was around one-hundred-billion-trillion, times infinity, plus 1, plus tax. So, it's quite thorough and without it, Java's lawyers will hunt you down if you try and stick the 'Java' badge on your implementation. Dalibor pointed out to me:

"The major argument against breaking the platform is that on the broken platform the wealth of good software written in the Java programming language will not work, so it would be a pointless exercise now, after 10 years of software development. No one would switch to something broken when they can use the real, working thing.
"One must also note that official and unofficial extensions to the Java programming language, like support for generics, have existed already for years without the platform breaking apart. The 'everything will break and collapse' argument has been thoroughly refuted by the history of the platform."

A typical real world example I have come across: Java applications are often bundled with their own local copy of a JVM (to simplify deployment, as opposed to relying on the user installing the required version). Say I spot a bug in a core class that's causing me a head-ache. I look at the source and notice it's a really trivial error. I correct it and resubmit to Sun. If it gets approved, I then I could be waiting up to 18 months for the next official before I can get hold of a JRE that fixes the bug which I can legally deploy to customers. I can't distribute my fixed version of the class. Therefore, depending on the bug, I have to sub-class and fix by over-riding affected methods. A lot of work for what was a simple fix (cue cries from the Aspect Oriented Programming crowd). If it's a JVM bug, then you've no chance. There are also developers who simply want to remove packages that are not needed by their application - no source changes at all, but even that is not permitted. Would this really be a problem?

Table of contents
  1. "Java, Page 1/2"
  2. "Java, Page 2/2"
e p (0)    44 Comment(s)

Technology White Papers

See More