Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Effort on the edge, Part 2

A fact-based analysis of the JCP's effectiveness

By Frank Sommers and Sonali Shah, JavaWorld.com, 01/31/03

Sun Microsystems introduced the Java Community Process (JCP) on December 8, 1998, to provide a blueprint for the Java community's activities. Almost from the start, the JCP became the target of intense criticism from the Java developer community: the JCP wasn't open enough, or efficient enough, or effective enough in promoting Java. Partly in response to those criticisms, the JCP has changed over time. In this article, we evaluate the JCP's effectiveness based on measurable facts of its four-year history to see if these criticisms are based on truth or mere perception.

Read the whole series "Effort on the Edge:"

• Part 1: Does the JCP adequately balance innovation with maintenance of Java's standards?
• Part 2: A fact-based analysis of the JCP's effectiveness

The JCP critics

A typical early complaint went like this, gleaned from a 1999 XML.org mailing list message sent by Simon St. Laurent:

The JCP may feel like an 'open' process if you're a mammoth, or even if you're a reasonably well-off saber-toothed tiger, but to us small mammals, it's the same old [stuff]...we get from standards organizations. We get to run around among the mammoth and saber-toothed tigers wearing funny lenses that blur our vision, and working with tools that may not have been created with our needs in mind.

In an editorial from the same year, titled "The Java Gated Community Process," author Elliotte Rusty Harold wrote:

If it seems a little strange that all of this work is going on behind closed doors without significant public input or awareness of its existence, that's the Java Community Process at work. The JCP is Sun's new procedure for adding to Java with input from its major commercial partners. The "community" is comprised of companies who are willing to pay Sun ,000-,000 a year to belong, as well as Sun's Java commercial licensees who pay even more to license the JDK source code. This is very much a gated community designed to keep out the riffraff like you and me and let Sun run things the way it sees fit.

More recently, a January 2003 article on Builder.com laments:

Many veteran Java developers are shying away from the Java Community Process (JCP) in large numbers and gravitating toward smaller developer communities to implement their new ideas. The JCP, once a place where developers were on a first-name basis with leadership and could email a question and get an answer within minutes, has become Java the Hutt: fat, sluggish, and difficult.

Not only have individual developers frowned upon the JCP, but so have many of the largest companies among Java's key backers. For instance, a comment about the JCP's attitude towards Web service-related standards prompted Stefan Van Overtveldt, program director of IBM's WebSphere product line, to opine in a December 2002 interview with Integration Developer News:

There might be significantly more pressure on Sun to submit Java to [another] standards body to really open it up. We have enough leverage to exert some changes with companies like IBM, BEA, and others driving for new ways of bringing in new services. [J2EE (Java 2 Platform, Enterprise Edition) is] driven as much by other members of the JCP as it is by Sun. In fact, 70 percent of the initial J2EE specification is [intellectual property and] technology we donated to Sun and the community. [For instance, the] transaction and messaging, and JCA (Java Connector Architecture) is IBM architecture.

An open Java standard has long been on IBM's, and other large Java backers', wish list. Since Java is a strategic tool for those firms, they prefer Sun to have as little control over the technology as possible. Bob Sutor, IBM's director of e-business standards strategy, echoes that sentiment: "Sun is a competitor to us and is not a neutral body. What we want is an industry-neutral body where no one company has too much power, and that body has to have jurisdiction over all of the Java specifications...If Java was an open standard, technologies like [Microsoft's] C# and the technologies it works with [like .Net] might not exist today" (from "IBM Pressures Sun to Free Java," David Berlind (ZDNet, September 11, 2002).

As if the barrage of criticism from individual Java developers and mammoth corporate Java sponsors were not enough, the most popular open source developer communities have also expressed strong dislike for certain JCP aspects. The only open source group with a JCP executive committee seat is the Apache Software Foundation. Apache used its executive power to cast a "nay" in the final approval of 14 JSRs (Java Specification Requests) over the past two years. Its reasons were not primarily technical. In voting against acceptance of JSR 47, the Java Logging API Specification, Apache's JCP representative explained the vote: "Regretfully, under the Merlin business terms, log4j (or any other potential independent implementation of this specification) cannot use the specification, nor can anyone implement this specification for earlier J2SE platforms...and it is on this basis that Apache cannot support this JSR." (For an overview of the JCP, including the various JCP voting stages, please see Part 1.)

Given that strong negative sentiment from practically all sides of the software universe, can the JCP survive? Since the JCP's primary raison d'etre is to advance Java and ensure that all Java implementations stay compatible with agreed-upon standards, any Java developer would be wise to start worrying: dark clouds are surely gathering on Java's horizons.

But are they? Is a developer's worry about Java's future justified?

In this article, we endeavored to answer those questions, not by listening to the "experts," but by looking at a few indisputable facts about the JCP. We examined publicly available information from the JCP Website to construct our own database and run a few analytic queries on that database to check on the JCP's health. The Website lists all JSRs, including not only their names and descriptions, but also the members in each JSR's expert group as well as the votes each EC (executive committee) member cast.

As we're writing this in January 2003, the JCP Website lists over 220 JSRs. Some JSRs are so recent that little beyond their names and descriptions are available. For the purposes of this article, we considered JSRs with significant history only; thus, we limited our inquiry to JSRs 1 through 200. JSRs 99 and 171 are special in that they address issues beyond Java technology, such as the JCP's procedures and structure. Since our focus is the JCP's advancement of Java, we removed those from this analysis. We also removed those JSRs that crashed and burned, that is, those that were withdrawn shortly after their submission for lack of interest or similar reasons (JSRs 2, 25, 26, 33, 39, 42, 44, 64, 71, 81, 84, 96, 132, 162, and 167). Our following comments are based on the remaining 183 JSRs. On a minor note: Some data items were not recorded on the JCP's Website, or were incomplete. When in doubt, we ignored those data items.

How healthy is the JCP?

If the JCP's vigor is determined by how many JSRs are submitted to it, and more important, how many JSRs successfully graduate from the process, worries about the JCP's demise are strongly exaggerated. As Figure 1 illustrates, the number of JSRs commencing their way through the JCP peaked in 2001 and slightly declined the following year. That decline may be due to our decision to analyze only the first 200 JSRs (thus excluding those submitted at the very end of 2002). But it might also be due to a more important indicator, one that bodes well for the JCP's, and Java's, future: instead of submitting new ideas to the JCP, Java community members rolled up their sleeves in earnest in 2002 and started completing existing proposals. Last year, 44 new Java standards achieved completion—completed JSRs have reached the "final release" stage.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.