Why Apache Harmony?

My last blog entry argues on whether Apache Harmony will succeed [1], but I need argue firstly why people really need Apache Harmony.

Here is the motivation given by Geir Magnusson, who was the project lead.

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 (Kaffe, Classpath, etc). There are also efforts that provide alternative approaches to execution of Java bytecode (GCJ and IKVM). All of these efforts provide a diversity of solutions, which is healthy, but barriers exist which prevent these efforts from reaching a greater potential.

But it didn't say what the real problems to solve with the open source Java implementation. Again there was an article two and half years ago summarizing the key problems that Apache Harmony probably could solve. That is <a href="http://dynamicsemantics.blog-city.com/whyharmony.htm">Clear problems that having Apache Harmony will solve</a>[2] by Floyd Marinescu. Repeat them below: <i><ol>

1. <li>Betting your infrastructure on technology from one vendor (Sun) who could one day stop it's offerings, either by going out of business, or changing priorities. Solution: An open source implementation can survive if independently if Sun dissapears one day or if suddenly the big vendors decide that there is more money to be made on some other platform, like Ruby. :)
2. <li>Java can't come shipped/supported by some Linux - Many free flavours of Linux won't distribute Java due to Java not being open source. As a result, software developed for these distributions will not be done in Java. Solution: An open source Java would be adopted by the Linux community, increasing the value proposition of the "write once, run anywhere" mantra, and causing a lot more development to be done in Java.
3. <li>Limited traction for desktop Java apps due in part to the linux problem - The Brazilians want Java to be part of the core, so they can have all kinds of desktop applications written in Java.
4. <li>You can't ship a custom JVM with your application. There are a number of reasons why one might want to do this. You might need JVM’s with custom features, or ship apps with parts of JVM's embedded (would you prefer a 2meg exe file distributable that combines a mini-JRE and your app, or 100KB JAR that needs the entire JRE?), or implement remote updating for JVM's (like Windows Update), or simply making it easier to install an app that depends on Java.
5. <li>Java is not available on all platforms that could benefit from it. Custom hardware solutions like hand held devices, kiosks, and other stuff that can't install a typical OS don't have Java implementations because no vendors will make enough profit to justify the effort and licensing fees. Solution: An open source Java means that corporate or government entities can implement custom JVM's that will run on those systems (think J2ME) and thus be able to leverage skill sets of existing java developers and investments in Java internally and for their customers.
6. <li>The US goverment might embargo our country and cut "us" off. This, especially for emerging economies is a critical point. Countries like Brazil, China, India that want to use Java heavily, at a national scale are making themselves dependent on US corporations if they base their infrastructure on Java. If the US embargo's their country, they will lose rights to upgrade or get on support on Java-based tools from US corporations, possibly Java itself (I'm not on top of all the legal here but this is what I've heard). The US has a long history of intervention in many parts of the world, especially South America, so this is a real and present problem. Solution: An open source Java means that a US embargo would not have any effect on a foreign country's ability to continue upgrading and getting support for Java and derivative tools.</ol></i>

I don't believe in some of the problems listed above, such as the "US embargo" stuff. But I do agree with one of them, i.e., customized JVM. So far as I know, there are companies who are unsatisfied with SUN Java, but can't customize it for their products. Here I want to give some of my bullets besides the customization point.

• 1. To have a Java really in public domain. Java is a programming language, but so far it is almost under SUN's sole control, even with the OpenJDK. Well yes the language is in public domain, but it is actually not if there is no implementation in public domain. Apache Harmony is the solution. This is not only important for some countries' strategy (which I said I don't believe in), but more important for the public to do whatever they want with Java. The first bullet in above list talks something similar.
• 2. To be a runtime technology vehicle. There are lots of runtime systems, but only Java is most mature (and possibly also .NET). The technologies developed here in Apache Harmony can be applied/reused in other runtime systems, and people want runtime supports can use Apache Harmony. For example, more and more dynamic languages have their implementations on top of Java, in order to leverage the maturity of Java. The other example is Google Android, which is not Java but reuses Apache Harmony.

Then why not OpenJDK? License really matters here. If JCP is really open, and if OpenJDK is really free, I believe OpenJDK will be preferred to Harmony. But it's not the case (yet). Note, TCK doesn't really matter in my points.

[1] http://xiao-feng.blogspot.com/2007/11/will-apache-harmony-succeed.html
[2] http://dynamicsemantics.blog-city.com/whyharmony.htm