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.
Figure 1 also illustrates that it takes time to complete a JSR. Although JSR 1, the Real Time Specification for Java, was submitted in late 1998, the first Java standard didn't emerge from the JCP until March 2000 (JSR 9, the Federated Management Architecture, not JSR 1, was the first JSR to complete the JCP). Many of the earlier JSRs were completed in 2002. If the trend continues, 2003 may see yet another wave of new Java standards coming out of the JCP, likely surpassing the number of JSRs that reached final release stage in 2002.
A frequent JCP criticism is that it takes too long for a new Java standard to steer its way through the process. That criticism flares up especially in the context of Web service-related technologies. In "Is the JCP Adequately Preparing Java for Web Services?" (JavaWorld, June 2002), Jennifer Orr asks whether the JCP's slow pace jeopardizes Java's emergence as a leading Web service implementation technology: "'It takes too long to bring JSRs from initial concept to a workable version,' says Humphrey Sheil, a technical architect. This sentiment has only increased since Microsoft released .Net, its competing Web services platform, causing industry analysts to declare that Sun has allowed Java to fall behind."
But just how long does it take to drive a JSR from idea to Java reality? According to our database, the fastest JSR—JSR 144, the OSS (operations support system) Common API—zipped through the process in a mere 225 days (just under 8 months). But, as Figure 2 shows, that is an exception. On average, a JSR requires about 670 days (about 22 months) to reach final status from inception. More recent JSRs seem to have shorter lifecycles. One reason for that acceleration may be that expert groups are getting the hang of the JCP. Another contributing factor may be the increasing participation of open source developers in JSRs, made possible by the recent changes to the JCP membership charter (more on that below).
Some JSRs seem to take an eternity. JSR 1, for instance, did not complete until January 2002, some 1,118 days after it began the JCP process. Figures 3 and 4 list the fastest and slowest JSRs, respectively.
Only 58, or about 32 percent, in our database of 183 JSRs have reached final release status as we write this. The rest are either in various stages of completion or have been rejected.
A Java standards explosion?
While some worry that the JCP does not produce needed standards fast enough, others are concerned that Java has too many standards already. Even if you account for a few JSRs that will either be rejected or abandoned along the way, if the past is any guide, before the end of this year, 50 to 60 new Java standards will graduate from the JCP. Can a Java developer keep track of all those new APIs and technologies?
No, according to Jason Hunter, who for two years represented the interests of the Apache Software Foundation on the JCP's executive committee. A leading open source advocate, Hunter gave a tutorial on the Java logging API at the O'Reilly Open Source Convention, in July 2002, in San Diego, Calif. In response to an audience question about the various Java logging APIs, Hunter said he no longer believed a Java developer could call himself an all-around Java expert any longer, given the myriad of Java technologies.
In a recent telephone interview, Hunter further noted, "There is an attitude in the [JCP executive committee] that if we don't have a reason to go against [a JSR proposal], then we won't, and that proposal will then be approved. It will lead to an explosion of different JSRs being proposed. How many of those will actually finish? Until a JSR is finished, it doesn't really matter...There has been an explosion in proposals, but there has not been an explosion yet in completed ones.
"Just because a JSR concludes doesn't mean that it's a Java API," continues Hunter. "It's not going to end up in the next edition of Java in a Nutshell. [The JCP] is a forum for creating Java specifications, but it doesn't mean that everything there is a standard in the Java language...If you want to have a Java standard for roofing, for how to determine tiles of a roof, that's all right. If you help the roofing industry, and if you get a bunch of players in the roofing industry to care, go for it. [But] it won't be in the JDK."
For a proposed Java technology to make it into the JDK, that proposal must become part of an umbrella JSR. Sun tightly controls what becomes part of an umbrella JSR adds Hunter. "So, here you have an open process, but at the end of the day, Sun decides what becomes a standard and what doesn't. That is going to be a sticking point in the future, I predict."