Open Source Java, part 2

After my post on Apache's Harmony project I have been watching the fireworks on the blogs and the mailing lists. One thing is clear: nobody quite knows what Harmony is supposed to be.

There are pros and cons. The main pro is that I discovered the BileBlog, a modern-age blog that reads like a good Jamie Zawinski opinion. In particular the flame about project Harmony is gem.

Unlike Mono, open source Java faces a big problem: there are a number of free commercial Java runtimes available for every operating system that matters. The group of people who would have contributed to a free java to scratch an itch are gone. From those who remain another large chunk will switch in a heartbeat to a commercial implementation the moment they run into missing features, scalability issues, the lack of a moving GC or a hard to debug problem.

So you must rely purely on free software advocates or people employed to clone Sun's Java for a strategic purpose.

To illustrate my point: Mark reports that for the two months leading to May 7th GNU Classpath had 299 commits and today is made up of roughly 900,000 lines of source code. Mono in the same time frame had 985 commits to its core class libraries and has roughly of 1,600,000 lines of code. The previous count is only for the core class libraries and does not include Mono-specific or Gnome-specific class libraries. The Mono effort is also three years younger than Classpath and five years younger than Kaffe.

For an open source Java effort to succeed, it not only needs to match the functionality of Sun's Java first, but it must offer functionality that is not available anywhere if it wants to attract developers to its core. Today there are probably two openings in this area. IKVM which makes Java and .NET run side-by-side and GCJ which turns Java code into native code.

Java and C#, CLI and JVM

Havoc last post bounces across every possible point.

I was not going to enter the language discussion on PlanetGnome, because it touches on too many topics. For one, I think that:

• Some key libraries must remain written in C. And we (The Mono Group) have a very good framework for binding GObject-based APIs into Mono APIs.
• We have a tendency to dump things into a library and hoping that every application will use the library to gain consistency.
  For example, recently a user mailed me to point out that although he can browse his files on a SMB share, he can not actually use any of his local tools to manipulate these files. It turns out that instead of doing the obvious thing, which was to ask the kernel to mount the file system the path we went down on was to use the Gnome-VFS to provide an SMB transport. And this works beautifully with the Gnome tools, but it does not work with any other tools.
• Mono right now shines as a platform for developing desktop applications, and we want to make sure that the developer experience there is great. Once we have conquered that space, we can organically reach into other spaces, but lets first get the first generation of Mono-based GNOME applications rock solid and shipping.
• I would very much like Mono-based applications to be part of the standard Gnome desktop release and get the stamp of approval of the Gnome Foundation. There is no mandate that all distributions must ship all the packages, so Red Hat can just not ship this.

I think my comments echo Mikael's post, which both Jeffrey and Havoc seem to have missed.

I wanted to follow up on a few things that Havoc mentioned:

• Graydon's contrast of Java and C# GUI code is a passable rendering of Java source code into C#, but is hardly an analysis of the technical issues.
  For an actual technical technical contrast there is Dare's C# for Java programmers document and the eight-part interviews with Anders Hejlsberg.
  Last year I was invited to present to the Red Hat Java summit in Boston. My presentation at the time focused on teaching to a Java-savvy audience the differences between the languages Java and C# and the JVM and the CLI, I have uploaded the slides here.
• The same universe of open source libraries being furiously developed for Java are being developed for .NET. Either direct ports, or re-implementations of the same concepts.
  Mind you, a lot of these open source technologies under development for Java and .NET give me a Freshmeat.net-deja vu. I still fail to see the correlation between all this server code and the Gnome desktop.
• I can only smile when I see that Havoc tells people to try Java 5 as an alternative to Mono. Specially considering that any use of Java 5 features will likely lock people into using Sun's proprietary Java.