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
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
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
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
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
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
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.