WebMink
Simon Phipps's personal commentary

Old Old

Ted Leung takes issue with my response to Anne's 'Jakarta on Mono' idea. He says:

Unfortunately, for Simon, he's throwing rocks in a glass house. Sun is the company that said they would standardize Java in ECMA and then backed out. Sun is the company that the ASF has had to beat repeatedly in order to fix the "process bugs". We still don't have an open source JVM. Until that changes, Java is not open. When people have to pay money to get certification, that's not open.

He's not very fond of Sun as I discovered when we met in Seattle a while back, and he's found some old rocks to throw. I'll try to debunk them; my intent is friendly, Ted!

"Sun is the company that said they would standardize Java in ECMA and then backed out."

As I have heard it told (I was, like Ted, at IBM at the time), Sun genuinely wanted to lodge the Java language standard at ECMA but found there was no way to maintain the trademark on the name 'Java' and thus be able to enforce compatibility. The desire to enforce compatibility was still a high priority at the time due to one of Ted's near-neighbours and Sun reluctantly withdrew from ECMA rather than create an 'embrace & extend & extinguish' opportunity. Instead it committed to making the JCP into at least as good an open standards forum.

"Sun is the company that the ASF has had to beat repeatedly in order to fix the 'process bugs'."

But they got fixed. I know personally how frustrating it was for people at Apache, but Sun's genuine intent always was (and is) to make the Java process 100% compatible with open source. I admitted in my posting that the progress hadn't been at the speed the independent spirits at Apache had wanted but Ted didn't quote or note that. The point of the posting though was that the intent is open and the bugs are fixable. I contend that's not true of C#/CLI.

"We still don't have an open source JVM. Until that changes, Java is not open."

Well actually we do, but that's not the point. What Ted means is that Sun hasn't made implementations of any of the Java platform profiles available in an open source format. But then, neither has IBM, which has clean-room implementations of various Java profiles but has so far declined to make their code open source. In fact, there are several members of the Java community that could create an open source implementation if they chose to. So far everyone seems content to use traditionally-developed JVMs from IBM, Sun, JRockit and others rather than one of the open source ones.

"When people have to pay money to get certification, that's not open."

As Ted indicates, the use of the Java specifications is open and royalty free on condition that implementors take the certification tests provided by the JSR specification lead before distribution. The reason for this one requirement is that Sun believe Java platform compatibility is the 'crown jewels' and is responsible for creating a diverse, rich, open market with a choice of (mostly) interoperable vendor and open source solutions. Take away the compatibility requirement and, Sun asserts, we'll fairly quickly see partial implementations of Java specifications that mix in proprietary code at the cost of compatibility and then, there goes the neighbourhood.

Certification costs real money - the test suite is huge and complex and usually requires extensive support from technical staff - so the JCP allows spec leads to charge for it, and indeed Sun, IBM, Nokia and others all do so. Of course not everyone has to pay when Sun is the spec lead as there's a fund to pay the costs for no-profit organisations. So overall this seems to be the best compromise; maintain compatibility, require certification, waive charges for non-profits. What's the problem?

At the end, Ted says "Let's take the CLI and chart our own course." Why not take Geronimo and chart your own course, Ted? Why build Microsoft's brand equity in C#/CLI? After all, as Noel Bergman has said, "history bears witness to the fact that EVERY time Microsoft has opened something up, it has been nothing more than the specialized dorsal fin of an anglerfish."

posted at 4:31 PM (UK) | Comment? (0 so far) | links to this post | |

On openness

In Anne's posting she talks about the idea of porting Jakarta to Mono, the project to implement C# and the core of the CLI from .NET on Linux. She says:

But from the moment Miguel initiated the Mono project, I’ve been worried about its future potential. I’ve feared that it would go the way of DCOM on Unix. (DCOM is an Open Group standard – and Microsoft retains ownership of its intellectual property.) A number of vendors implemented DCOM on Unix, but almost no one ever used it, because DCOM is pretty worthless without a bunch of application-level class libraries, such as ODBC, OLE DB, ADO, and ASP to run on top of it. Microsoft never released these specifications to the public, so these technologies have never been available for Unix. Hence DCOM on Unix faded away into irrelevancy.

With DCOM back in our minds again because of its exploitation by the Blaster worm, the reminder of how DCOM was 'donated' to Open Group as a marketing stunt is a good reminder that the path Microsoft has taken with C#/CLI is not new. Another expression of 'openness' was the availability of NT on chipsets other than Intel, which withered because Microsoft was really only interested in NT on Intel and left the really active maintenance of the code to partners who couldn't keep up, that NT/Intel was the only really viable platform.

What we learn from each of these forays into openness is that it doesn't matter how sound the vehicle being used to express the apparent 'openness' is (ECMA for C#, Open Group for DCOM, partenr community for NT), what ultimately matters is the open spirit of the originator. If their intent and method is essentially open, the process bugs get fixed along the way and more and more becomes open.

In the case of Java, things have gradually opened up to the point where Apache are able to implement the whole of J2EE (in their Geronimo project). The process bugs (there have been plenty over the years and as Anne hints there are still a few to fix) resulted in the most part from the design of the process by humans. Sometimes it took waaay too long to fix them, but the underlying spirit has remained an open spirit that's resulted in increasing openness. The result has been a rich and diverse marketplace with many strong players, and for J2EE there is wide choice at every stage for the developer.

So when Anne proposes

So the way I see it, in order for Mono to succeed, we need to develop a set of open frameworks, engines, utilities, tools, APIs, and class libraries that run on top of it.

I am left asking, why bother? Why not instead support Geronimo? What is the IP encumberance that makes Geronimo unsuitable? The history of the Apache project is that it has acted as a gadfly to Java, causing the (mostly unintended) process bugs to get sorted. I anticipate Geronimo having the same effect, 'outing' the bugs and getting them addressed. Supporting it will strengthen the openness of Java and help ensure a future for choice. My instinct tells me that getting developers working on C#/CLI projects to re-invent the Java wheel will not have the same effect.

[Also posted to java.net]

posted at 5:25 PM (UK) | Comment? (0 so far) | links to this post | |

New read

Anne Thomas Manes has started writing a regular journal - take a look. Anne & I joined Sun at about the same time, but as you'll note she's no longer there.

posted at 5:01 PM (UK) | Comment? (0 so far) | links to this post | |