This post originated from an RSS feed registered with Java Buzz
by Mats Henricson.
Original Post: In defense of the JCP, part 1
Feed Title: Code:Q
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Mats Henricson's weblog
There's a lot of thrashtalking these days of the Java Community Process (JCP), i.e. the process with which new Java specifications and standards are developed. Beginning today I will write down my thoughts about the JCP. I'll write it in pieces so as to focus the discussion a bit. Just to make it all clear, I do not work for Sun. In fact I am unemployed. But, I am a fan of the JCP, even though I am not currently a member. I plan to be, but haven't made the leap just yet.
Sure, the JCP has its drawbacks, and I will elaborate on that later on, but the alterantives are much worse. Also, to make things clear, I was a member of the X3J16/WG21 committee that created the C++ standard. (Throw the tomatoes now, so that we can get over it.) I've seen how ANSI standardization of a language works, and I think I know a bit about how ISO works too, but I'll come back to that later.
Today I'll elaborate a bit on the ways in which Sun is granted special priviliges in the JCP. Many people claim, quite loudly, that the JCP is run by Sun, and is therefore not open. It turns out there are three ways in which Sun has granted itself special priviliges in the JCP:
Sun is a permanent member of the Executive Committee (EC) for both SE/EE and ME.
Sun may veto any incompatible changes to the language or virtual machine.
Sun may block the creation of a new profile.
I think it is absolutely natural for Sun to be a permanent member of the ECs. After all, they invented the language, still maintain the J2SE core libraries, and own the Java trademark. Sure, this is not the way the ISO works, but I think it isn't much to whip up a froth about.
Anyone remembering the standardization debacle about 5 years ago can understand why Sun gave itself veto power to block incompatible changes to the language. OK, now, that is history. What about today? Well, Sun is pushing through changes to the language like never before in the history of the language! And, Sun has never (at least never publicly) blocked a change to the language, so I don't think we need to worry about this issue.
Lastly, Sun has granted itself veto power so it can block any attempt to create a new profile besides the ones we have now: ME, SE and EE. I'm fairly well educated about the SE and EE profiles, while the ME profile seems like a mess to me, so I shouldn't claim I'm an expert on this. But, it does make sense to limit the number of profiles. Why? Because it would make it harder to get your application to work if it ends up being deployed on a profile different from the one you developed it for.
It is pretty clear that Sun benefits from being a permanent member of the two ECs, but that is also in practice true for IBM, BEA and Nokia, which all three are in both committees, and will probably remain there for some time to come. But except for this permanent membership, Sun does not benefit itself from the special priviligies it has given itself in the JCP. By blocking incompatible changes to Java, or a new profile, Java the language may, or may not, benefit. Sun does not.
My conclusion is that Sun does not have much more power than any other member in the ECs, and I think it is not true that Sun runs the JCP in any other way than by being the most active member. That was true also for AT&T Bell Labs during the standardization of C++. Several key members of the committee were employed at Bell Labs, and noone had any problems with that. It was just natural. They invented the language, and had lots of experts willing to do the often boring work of whipping up standardese (the boring but precise way standard texts are written to be precise).
In my next entry about the JCP I will talk about the possible alternatives.
Previous Topic
