Stuck up a Mountain: Open Source for Open Source’s Sake?

• By Matt Stephens
• May 12, 2005

The recent proposal to the Apache Incubator PMC to create a brand-new, open source Java runtime platform brought one, inimitable question into my mind: Why?

To be fair, the proposed new VM project, Harmony, does seem like a great, exciting proposition: an entire Java runtime, built from the ground up to be independent of Sun's implementation. This would, in theory at least, open many doors for Java into the open-source world, where it's often regarded with suspicion due to its 'not-quite-open, not-quite-closed' status. So, a brand-new Java runtime to make Java (which is already free to download and free to use) more palatable for some people, who can already use it on their own free projects. Hmm...

I could be cynical and say that Harmony answers a wave of discontent which has swept through at least a handful of open source advocates: Sun, evil blackhearts that they are, aren’t content with simply allowing people to use their reference JVM for free and to make millions of dollars off the back of their hard work. So why don’t we make our own JVM, and do what Sun was too evil to do: make it open source. Yeah!

The (actually very level-headed) proposal to Apache begins: “There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform, and there are many ongoing efforts to produce solutions.”

Sorry but I just don’t see it. A clear need? Aside from a very few people clamoring loudly for Java to be open-sourced, the vast majority of developers seem quite happy to use Sun’s Java runtime for their commercial (and open-source) applications. If for some reason you don’t want to use Sun’s (increasingly excellent) JVM, there’s no shortage of alternatives on a variety of different platforms.

It’s difficult to see what problem such an ambitious project would solve. If the proposal read: “We want to do this because it would be a really, really cool and fun challenge, like climbing a mountain. Write our own VM, zowee! We won’t further humanity’s cause but it’ll look great on our resumes,” then that might ring less hollow.

A commentary on Project Harmony was blogged by Sun employee Graham Hamilton.

This commentary welcomes Harmony and hints that Sun will provide assistance with the new project (though the extent of that assistance isn’t specified). However, the commentary is also guardedly worded, and at one point Graham says:

“Personally, I am not entirely sure if the world really needs a second J2SE implementation, but at the same time I am also glad to see that all the effort we put into getting the rules and the licensing issues straightened out is actually proving useful!”

He hits the nail on the head – it’s great that Apache are able to embark on a project like this, but what’s the point? Much like climbing a mountain.

Existing Runtime Libraries

As it happens, there are already some Free Open-Source Software (FOSS) alternatives to Sun’s own JVM (not to mention several commercial, generally more specialized alternatives, such as BEA’s JRockit). The most promising of the FOSS Java runtimes is GNU Classpath. Actually Classpath itself isn’t a JVM, it’s an implementation of the core Java class library. But a variety of JVMs have been built using Classpath as their library implementation (including IBM’s Jikes “Research Virtual Machine”).

Classpath actually demonstrates quite ably why a FOSS Java runtime isn’t such a good idea. Classpath has been a long time in development, but is currently (April this year) only at version 0.15. It still doesn’t offer 100% coverage of the current Java APIs. In November last year they proudly announced that they had reached full API compatibility with the ancient, and horribly obsolete, JDK 1.0.

This means that your Java program may not run correctly (or at all) on Classpath, especially if it uses Swing. This isn’t the Classpath developers’ fault: they’re working hard on a seriously tough problem. A Java Virtual Machine is a big, uber-complex thing. To create a half-decent (and more than half-complete) JVM from scratch, you’re going to need money, lots of, and programmers, lots of. And bucketloads of VM research to exploit. Add to that that the Java spec gets updated with lots of new features every year or so, and it quickly becomes obvious that the open-source VMs currently out there can’t even keep up, let alone push ahead with new and innovative features to justify their existence.

This chart gives a good indication, both of the distance Classpath has to go in order to reach 100% compatibility with JDK 1.4, and of the sheer enormity of the Java runtime library. Implementing all of that from scratch is a huge task. With Java 1.6 already under development by Sun, the Classpath team haven’t even begun on Java 1.5.

Classpath, though reportedly well-written, has languished in “nearly-there” stasis for so long because it doesn’t have the resources, the legions of developers or the bucketloads of VM research and IP to keep it relevant. Harmony does stand a better chance, assuming it gets off the ground, because it will have Apache’s clout behind it. It’s likely that this will attract many more developers than have been attracted to Classpath. Harmony will still be a long, hard, perilous mountain to climb though.

The question has been raised about why Apache don’t just start with one of the existing FOSS Java JVMs or class libraries as a springboard. They could save at least a year, maybe even 2 years’ worth of hard slog as a result. The most concrete answer I’ve seen so far is that the licenses are incompatible. GNU Classpath uses the GPL (actually its license includes a special exception which makes it more like the LGPL), whereas Harmony is all set to use Apache’s own not-so-viral license. Spare me.

When the License Drives the Product (When the Baby beats the Nurse?)

Justifying a project's existence because of license issues just doesn't seem like a very good idea. The license should be driven by the needs of the users, the product, and its creators, not the other way around. When a major new product is created in order to satisfy the demands of the license, then something somewhere has gone seriously wrong.

Watching the discussions that are going on around the announcement of Harmony, it strikes me that those involved are in love with mechanism, in love with the intricacies and subtle incompatibilities of their respective licenses, as if open source is the source of all light in the universe. The damage being done by incompatible open-source licenses – or rather, by peoples’ love of them – can’t be measured. For example, if people stopped bickering about the licenses and just got on with it – recognizing that they’re really working towards a common goal (open-source) – then Harmony would be a year ahead of schedule on day 1.

We must also question why there needs to be an open-source JVM at all – this brings us full-circle back to the original question, Why? To all intents and purposes, the Harmony proposal purports to create an open-source, compatible clone of Sun’s own Java runtime. Compatibility is admirable – without it, Harmony wouldn’t be much use. But beyond that, there just doesn’t seem to be anything particularly wonderful or groundbreaking about this proposed new product.

If Harmony was being announced to fulfill a particular technological or business need, then it would be a different matter. If Harmony was being created with the goal of being super-fast, or super-stable, or (for example) being “AOP-enabled” from within, then its existence would be justified. Its goal should be something innovative and enabling but which a corporation might not be able to justify supplying for free – just what open-source is useful for. But... because the licenses aren’t quite right? That’s open-source for open-source’s sake, which is a flat waste of time.