This post originated from an RSS feed registered with Java Buzz
by Mats Henricson.
Original Post: In defense of the JCP, part 2
Feed Title: Code:Q
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Mats Henricson's weblog
In this piece I will look at the alternatives to the JCP. First it is important to remember what the JCP does. It creates additions to the Java environment in the form of Java Specification Requests (JSRs) that consists of specification documents (specs), reference implementations (RI) and Technology Compatibility Kits (TCK) which is the tests that must be passed to assure that an implementation of a spec is compatible.
This is unique! Never before (at least to my knowledge) has a standardization group required that all specs are accompanied by a RI and a TCK. Well, does it matter? Yes it does!
The RI assures that the spec can be implemented. Don't laugh - some parts of C++ templates, for example, are so complex that it wasn't always clear they could be implemented in any reasonable way!
The RI is to standards what Test Driven Development is to software engineering. It assures that the spec describes something that is useful, well designed and has reasonable performance.
The RI makes it possible for early adopters to start using a spec even before there are any real implementations available.
The TCK assures that a user can use an implementation of a spec and be reasonable assured that it will actually work. Think JBoss. ;-)
The TCK makes it possible, with some certainty, that you can replace one spec implementation with another, if you so wish. Think servlet containers.
The TCK forces spec implementors to stay within the spec, and not try to force an incompatible implementation upon users. Think Visual C++.
The specification itself is freely available. This may sound obvious, but for a long time, perhaps even now, ANSI and ISO charged a non-trivial fee for a copy of the standards they had approved. It was one way in which they made money.
If we compare this to other ways to standardize languages and libraries, its advantages becomes more clear.
Apache - only a RI, does not in itself create a TCK or spec, even if it often implements a spec.
ECMA - only a spec, no RI or TCK.
ANSI - only a spec, no RI or TCK.
ISO - only a spec, no RI or TCK.
IEEE - only a spec, I think, but I'm not totally sure.
W3C - only a spec, I think, but I can't claim I know much about the inner workings of W3C.
Now, lets scrutinize them, one by one.
Apache is not a standardization group in any way, so it cannot be used as a standards body for Java.
ECMA, the same organization where C# is standardized. Now, what is the ECMA? Officially I think it stands for European Computer Manufacturing Association, but I think they don't want to stress the "European" part of it any more. Anyhow, it is a club for big elephants. Technically, your company may join the ECMA and send you to their meetings even if the company revenue is less than a measly 100 million swiss francs (about US$ 75 million)! I'm not making this up - it is the official rules of the ECMA! As an individual expert you can participate in their meetings, but it is really hard to get in. Here is a quote from an email an ECMA representative sent me: "Participation in an ECMA task group as an individual is not usually done, unless the individual has unique qualifications not represented by the existing task group. This must be approved by the committee chair, as well as the secretary general of ECMA." Now, hands up who wants to use ECMA for Java!
ANSI is an american standardization organization, but has handled many international standards, such as C and C++ (in tandem with ISO). ANSI is better than ECMA in that it allows smaller fish to swim along, but there is a cost of $495 per year, which is peanuts for a company, but significant for individuals. However, you have to be a US citizen, or work for a US based company to be a member with voting rights. The rules makes sense for a standards organization of a country like the US, but it doesn't work if you wish Java to be a standard developed by an international community. This disqualifies it for Java standardization, I think.
ISO is the International Standardization Organization where only countries have a vote. So, if you want to voice your opinion, then you have to go to the local ISO meeting in your country, and try to convince your fellow countrymen. As anyone can understand, the process is very slow. It can take years to get something through the grind. I don't think doing Java standardization only through ISO is such a good idea. Possibly in tandem with another organzation, where ISO can mostly rubber stamp it at the end, but there are no guarantees when it comes to ISO.
IEEE membership costs $143 per year. They haven't really standardized any programming languages, so I'm not sure if it is such a good idea to go through IEEE. But I don't know too much about IEEE.
W3C is not really for individuals, according to their membership page. Quote: "W3C does not have a class of membership tailored to, or priced for individuals. However, an individual who wishes to join as an Affiliate Member may do so. Our processes are designed for organizational participation, and we do not have the support structure to handle large numbers of individual members." Affiliate membership is a whopping $5,750. It is a bit unclear if that fee is for one or three years. Now, hands up who wants to use W3C for Java!
It also seems clear to me that the JCP works, at least very often. Sure, some JSRs are total failures (over 15 of them are dead), while some others are just very late. Still, a rather recent study shows that on average a JSR is finished in less than 2 years, and that timeline is getting better. That may still sound like an eternity, but in standards circles it is like greased lightning. It took 9 years to get a finally approved C++ standard! Sure, the comparison isn't fair, but you get the picture. Remember, if you just want to develop some software, ignore the JCP completely and just do it.
Let me also be clear about one other thing: Sun is really bold in letting individuals into the JCP, for free. The risk is that lots of whackos or noisy people join expert groups and drag down their productivity. The C++ standards process had a few pretty disturbing incidents, and I'm sure it also happens in the JCP. I'm sure some spec leads wish they could throw out some people from their expert groups. But I think Sun did the right thing, and they should be applauded for this. It has never before, to my knowledge, been possible for individuals to be a member of a standardization organization for free.
Now, what about the Executive Committee, can individuals join? Yes, they can, but it is very uncommon. Doug Lea is currently the only exception, as a member of the J2SE/J2EE EC. Not many individuals can wave the kind of reputation Doug Lea has to wrestle himself into an EC, but it is certainly possible. Please also note that Apache is a member of the J2SE/J2EE EC.
In my next entry about the JCP I will talk about "open sourcing" the whole thing.
Previous Topic
