Geir's Blog - But is it Java? (or "Will Java be like trains in Europe, a two-class system...")

But is it Java? (or "Will Java be like trains in Europe, a two-class system...")

[ geir ] 07:04, Friday, 22 December 2006

Lately, I've been thinking a lot about the question "Is it Java^TM?", from the perspective of open source and free software implementations. I'm quite smitten with Apache Harmony (obviously), and there are lots of other implementations of piece-parts (GNU Classpath, Kaffe, GCJ, etc) as well as the 800-lb gorilla that has just started to show up, Sun's OpenJDK project.

So we have lots of code out that that claim to be implementations of the Java SE specification, but what actually makes those implementations "Java^TM", or as a Sun branding pedant would have it, "Java^TM compatible"? I'm actually a True Believer in the compatibility promise of Java - I think that it's very important - as a software developer, knowing that my runtime platform is Java (or "Java compatible") means that, in the memorable words of Rob Gingell, "my bytecodes won't be lied to". While this explicitly means that my programs will run as I expect them to, the implicit benefit is that I'm free of vendor lock-in. I can take my program and move it to another Java implementation, on another hardware platform, on another operating system. My choice, my freedom.

Traditionally, the way you know you have Java (or an implementation of one of the many JSRs that augment the base platforms) is if the implementation passes the "TCK" - the Technology Compatibility Kit - a test suite that any implementor can obtain from the spec lead to demonstrate that their implementation is compatible with whatever spec they've implemented. When you pass the TCK, you can claim compatibility with the spec and as a side benefit, you get all the "necessary IP" held by any members of the Expert Group that created the spec, a mechanism that keeps any member of the Expert Group - including the Spec Lead - from acting like a patent troll, being able to commercially control usage of the spec through patents. Java is an "open" ecosystem, right? ;).

So how is this related to the blossoming of open and Free implementations of Java? I was reading this recent blog post by Chris Adamson of OnJava. He asks if the DLJ - the Distribution License for Java - matters anymore, based on the premise that the linux distros will be doing their own packaging :

"Of course, with the GPL release of Java, the need for the DLJ would seemingly go away"

Does it? What exactly is the result when the distros compile and package the OpenJDK source? I'll argue it's by definition not "Java^TM" (or "Java compatible") because it hasn't passed the TCK. I'm sure that it's reasonably good software - after all, it's based on the same source code that Sun ships as tested binaries under their proprietary licenses. If a distro, especially a commercial distro that is feeding commercial enterprises, wants to deliver commercial-grade (whatever that means) infrastructure, I'm betting their customers will demand "Java^TM compatible", not "something based on the code that goes into Sun's implementation of Java".

One of the "success drivers" of open source is the notion of "good enough" - people are very happy to use solutions that are good enough to get the job done. They aren't necessarily the fastest, or the most stable, or full-featured, or pedigreed, but are fast enough, stable enough, functional enough, or "pedigreed enough". So whatever you get when you compile OpenJDK may be "good enough", but it won't be "Java^TM" or "Java^TM compatible". Now, I'll risk being accused of spreading FUD here, but I really wonder - is there an implicit "fork" coming in Java, with users choosing between "Java^TM compatible" runtimes and ubiquitous "Good enough" runtimes? (Maybe that's why I get winks and giggles from my Free Software friends when I ask them questions like this....) Last week, I spent some time traveling around Belgium and the Netherlands. Trains are two-class - first class means you probably get a seat, second class is good enough, but both tend to get the job done. (To really screw up this metaphor, I suppose I can conflate .NET/Mono and Amtrak as examples of the bad things that happen when you have a single supplier...)

I'm really not interested in seeing this. I've spent a lot of time in the last few years helping create compatible implementations of Java specifications in open source, including helping drive awareness of the value and utility in the Java compatibility promise. I'm hoping I'm wrong here - that this is a hypothetical, and that a solution will emerge where the Linux distros are shipping tested binaries. If I put on my tinfoil hat, I can see that this fits with my Walled Garden Theory about Sun's open source Java strategy, but the long term consequences are so disastrous, I can't believe it (even with the tinfoil hat...). Two obvious solutions - 1) OpenJDK releases binaries under the GPL, so that the distros that are happy re-packaging binaries from others can do so, and 2) those that need to build from source simply get the TCK from Sun and test what they ship. I suspect that the latter will be the way it will have to happen, given the need for the distros to build from source (and it will be fun to watch), but it leads to the outcome best for the ecosystem - preservation of the Java compatibility promise, and the long-term health of the platform.

Bascially, the JCP is sub-optimal in that regard, that it currently allows TCKs and RIs to be kept closed by default. I hope ASF and others with the pull in the JCP (i.e. you :) will use JSR 306 as a way of changing the default rules of that game to be more suitable for independent developers, who don't have large foundations and/or companies behind them. :)

I believe that easy, unencumbered access to specifications, RIs and TCKs will both improve the state of the art of implementations of JSRs, and at the same time allow re-distributors and customers to verify compatibility claims/guarantees they offer in their target environments easily. That's been something I've been arguing for as long as I've been working on Kaffe, Classpath, Harmony and all that cool stuff.

I'd be interested to hear what your experiences are with the way things were done in the JDO2 project, which was the first JSR to feature an open source TCK and was conducted under ASF's umbrella along with the RI, afaik.

The compatibility promise is a great property of the Java platforms, and JCP-driven specifications. Having test suites to go along with specifications is one of the things that make the JCP a good organization.

As more RIs turn to be implemented as Free Software, I think it's time to start empowering users and developers alike to be able to easily verify compatibility of their works that build on the RIs, in their specific deployment environments, so that they can see if some change in their environment breaks the original compatibility promise.

Having worked on Kaffe & GNU Classpath for a couple of years, I know that subtle changes like the threading model of linux & glibc, the compiler toolchain, or changes in libraries used by the runtime & the class libraries can have very unexpected effects, that only testing on the platform the user is deploying is able to catch.

--Dalibor Topic, December 22, 2006 07:43 AM

Geeze, that was quick :)

I actually don't mind closed RIs, because the RI is there simply to prove that the spec can be built, not as a base seed or roadmap for other implementors. Letting people monetize the RI means that the JSR process is less financially daunting to small ISVs and such.

As for the TCK? Well, I think that seeing OSS TCKs would be great and one of our goals at the ASF, but honestly, I don't think necessary. I think that free-of-encumbrance access to TCKs is necessary, as we want as few barriers as possible to encourage people to support the Compatibility Promise. Transparent TCK licensing terms are a first step, of course, and currently an issue in JSR-306. There is the issue of paying for TCK development - it can be an expensive proposition - but right now we have that nice situation where TCKs are offered at no cost to qualified non-profits, individuals and academics.

As for the JDO2 project at Apache, it's another example of "much ado about nothing", in that the whole thing went smoothly, and the sky hasn't fallen - it shows that there's no technical reason why a TCK can't be open source. Derivative works of the TCK aren't the TCK, and don't give the user any IP rights or claims of compatibility. Therefore, the integrity of the TCK isn't in any way compromised by the fact that it's open source.

Of course, one might argue that JDO2 doesn't have the same commercial interest as Java SE or EJB3 or other JSRs, but those are commercial reasons to lock up and control the TCKs, reasons that I think are inappropriate for an ecosystem that purports to be open.

--Geir Magnusson Jr, December 22, 2006 08:01 AM