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:"

Page 2 of 3

The JCP critics

A typical early complaint went like this, gleaned from a 1999 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 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. Numbers of new JSRs and JSRs that reached final stage. Based on 183 JSRs submitted between 1998 and November 2002. Click on thumbnail to view full-size image.

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).

Figure 2. JSR completion times, starting with the time a JSR is accepted. Based on 58 JSRs reaching final status between 1998 and November 2002. Click on thumbnail to view full-size image.

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.

Figure 3. The fastest JSRs
Figure 4. The JSRs that took the longest to reach final status

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."

JCP dynamics

Sun's dominance of the JCP has already been a contention point in the Java community. Sun is Java's "original contributor," and accordingly reserves special veto and voting privileges in the JCP charter. The most important is that Sun has a final say in what becomes part of J2SE (Java 2 Platform, Standard Edition), J2EE, and J2ME (Java 2 Platform, Micro Edition). Rob Gingell, Sun fellow and chief engineer who chairs the JCP, explains that special power with an analogy:

"The UN [United Nations] has a security council with five permanent members. The OSF [Open Software Foundation] had founder members and 'other members.' WS-I [Web Service Interoperability Council] now appears to have the same, as does UDDI [Universal Discovery, Description, and Integration]. The world is loaded with examples where those who (rightly or wrongly) felt they'd put considerable skin in the game created structures that preserved that position. Sun created Java, stakes substantial parts of its future on it, and has had to defend it against determined assaults that would have had the effect of undermining its future. We're unapologetic that we have the means to act in Java's best interest.

"IBM and indeed many JCP members can reasonably assert that Java is successful partly because they participate," Gingell continues. "That's true. The UN is what it is because nearly 200 nations participate in it too. That doesn't cause the five permanent members to stop having their permanence. Of course, the JCP recognizes some of this in the current structure. It should be noted that IBM does not run for its seat on the ECs, having been appointed there by Sun since the ECs' inceptions and eagerly having reaccepted appointments to its seat on the ME [Micro Edition] EC just this year. [IBM's seat] is in essence a permanent seat because it's hard to imagine a circumstance where Sun wouldn't simply reappoint IBM because it just wouldn't be credible to do otherwise, no matter the state of other matters between the companies."

Apart from the special powers the JCP charter grants it, Sun is the busiest JCP member when it comes to shaping JSRs. Of the 183 JSRs in our database, Sun has participated in 166 expert groups. As Figure 5 shows, IBM came in a distant second, with membership in 104 JSR expert groups. Oracle, HP, and Motorola are next in line, participating in less than half as many expert groups as Sun.

Figure 5. Java's movers and shakers: membership in expert groups. Click on thumbnail to view full-size image.

When it comes to initiating and leading JSRs, Sun is also by far the most assertive. But it is no longer true that Sun dominates the JCP's agenda. In total, 531 experts contributed to the 183 expert groups in our database. When counting experts, we counted JCP members, not individuals, since larger organizations are often represented by different employees in different JSRs. For instance, if Oracle had 10 different employees working on JSRs, we counted them as only one (Oracle, the JCP member).

Of those 531 JCP members participating in JSR expert groups, 50 acted as JSR leads. Figure 6 shows which members led the most JSRs. Sun leads, playing leadership roles in 84 JSRs. But that's less than half of the JSRs in our database. Less-dominant JCP members (noted as "Other" in Figure 6) led no less than 31 JSRs, followed by IBM and Nokia. Sun seems to take a hands-off approach when it comes to JSRs dealing with the telecommunications industry: Telecordia, a telecommunication firm, led five JSRs, all relating to that industry.

Figure 6. Distribution of JSR expert group leadership

The dynamics of JSR expert groups is increasingly vibrant. Gingell notes, "While it may be true that different companies have agendas they fulfill in part through their actions in the JCP, those they have sent arrive as problem-solvers. The expert groups are organized around a technical problem and thus often have objective means of examining and working on that problem. The structure of expert groups tends to give the leader a lot of sway over how the work is accomplished."

Expert groups are growing increasingly larger. Figure 7 shows the most populous groups. The least popular ones are often new JSRs that have not gathered enough interest from JCP members yet.

Figure 7. Expert group sizes. Click on thumbnail to view full-size image.

Leading a JSR expert group is a demanding and time-consuming task. Farrukh Najmi, lead for JSR 93, the Java API for XML Registries (JAXR), and a Sun employee, says that developing the JAXR API took 50 percent of his time: "The remaining 50 percent of my time was spent defining the ebXML Registry standard. The JSR work was my main job at Sun. It took long hours and most of my free time to do the JAXR API in just over one year. Sun also provided a reference implementation (RI) team of two engineers, one engineer to write the Technology Compatibility Kit (TCK), a quality assurance (QA) team of two engineers, a document writer, a release engineer, a program manager, and a project manager."

The RI and the TCK is a unique demand the JCP imposes on a JSR expert group and its lead. To our knowledge, no major standards effort has that requirement. However, thanks to those requirements, once a JSR reaches final release stage, any developer can download and start using the reference implementation. In addition, third-party implementations can use the TCK to ensure their work complies with the JSR specification. Those demanding deliverables are the most likely reason some JSRs never complete or take a long time to reach final status. A team effort helps speed the process.

According to Najmi, JSR 93's workload was divided as follows: the RI team did the RI implementation beyond the initial prototype; the TCK engineer implemented the TCK; the doc writer wrote all documentation including a tutorial; the QA team tested the RI; the release engineer managed RI releases; and the program manager managed many details of the project, such as schedule, and was responsible for delivery.

The JSR lead often takes the lion's share of the work. "My personal activities started with a proof-of-concept prototype implementation," says Najmi about the JAXR JSR. "Later, most of my time was spent writing the specification and API classes (and Javadoc). A major part of my job was developing and organizing strategy and vision for the standards and API. Finally, I did a fair amount of evangelization. Late in the JAXR JSR cycle, I also started an open source project to implement a JAXR provider for the ebXML Registry."

Open source developers play an important role in completing a JSR's deliverables. Increasing participation from the open source community may have directly contributed to shortening the lifecycles of more recent JSRs (see Figure 2). "From my experience, open source people and other individual experts are great contributors on expert groups because they care. They're there by choice, not because of a company assignment." says Hunter. In addition to having been Apache's EC representative, Hunter is an expert group member on the JSR defining the Java Servlet Specification and lead of the JDOM JSR.

"Company leads, on the other hand, are quiet more often than not," continues Hunter. "The average output by an open source advocate is five to 10 times the average output of a corporate participant. On weekends, there is a whole thread managed, whereas, how many corporate people are working on the weekends? Corporate people tend not to speak up in debates." Hunter wonders whether some corporate participants bring the JCP discussions into their own company meetings and come back to the JCP with responses to those discussions that basically say, "This company's position is X."

The JCP embraces open source

The JCP, however, did not always welcome open source ideas. Part 1 described why Java's Write Once, Run Everywhere promise has more to do with an open binary standard than with open access to source code. But few people inside Sun understood that distinction. As a result, during the JCP's first years, Sun's licensing terms for Java shut off possible contributions to JSRs from the open source community.

"The licensing around JSRs was incompatible with open source ideas and with open source implementations," notes Hunter. "The specs would be licensed in such a way that implementations had to do certain things. One of those things was that the implementations had to restrict user rights in a way that open source licenses couldn't restrict user rights.

"We [the Apache Software Foundation] didn't enter in trying to tell Sun that they had to relicense any particular technology in a certain way. [We were only asking that] they not restrict open source implementations of JSRs. What would Apache's motivation be to participate in the JCP, if the result of a JSR could not be implemented under Apache's own license. So [Sun was] stuck between a rock and a hard place: on the one hand, the collaboration with Apache is very good for Java—Jakarta has really helped adoption. On the other hand, Sun really liked the existing business model under which Java is licensed. Apache was requiring that business model to change."

Initially, Sun's business model for Java assumed that the Write Once, Run Everywhere promise was incompatible with open source licenses: if anyone could change Java, and still call it Java, how could one be sure that a piece of Java code ran on all Java platforms? Since the inception of the JCP, time has proven that open source actually fosters compatibility. "The number one thing keeping the Web open is Apache," says Hunter, "and the fact that Apache is 100 percent dedicated to standards compliance. With 60 percent market share, Apache could make standards themselves. But they don't—they always try to be as rigid in accordance with W3C [World Wide Web Consortium] standards as possible. On the Web, where you have very few problems between clients and servers, the biggest reason is the popular open source product in that space. Commercial vendors have to differentiate. No one is going to pay money if you don't differentiate your product and implement only the standard. Well, Apache can implement the standard. That's key."

At the root of Sun's fear of incompatible Java implementations was Microsoft. While Microsoft did try to undermine Java's prominence by creating an incompatible, Windows-only implementation, Sun either overestimated—or underestimated—Microsoft's power. "Microsoft doesn't need an open source codebase to start with," notes Hunter. "They have enough developers that they can develop anything. If Microsoft wanted to create an incompatible [Java] implementation, they didn't need an open source project to get the ball rolling."

It has taken a while for Sun, and other key Java players, to understand that open source does not lead to a proliferation of incompatible versions. "When I teach open source," says Hunter, "the first thing I ask people is, 'Who can change the Apache server?' And they answer, 'Everybody, because it's open source.' Well, if that's true, then how do you maintain security, if everyone can change the code? And they say, 'Oh, only Apache people can change it.' Well, how come only Apache people can change it, if it's open source?...Only Apache can ship something called Apache. You can take the code and do whatever you want with it, but it won't be Apache. Similarly, if you have an open source RI and TCK, I can take that code and do something else [with it], but I can't call [that changed version] the RI and the TCK. It took a while to find someone at Sun who understood this. Rob Gingell was that man. That was the beginning of the solution, because he got it immediately."

The result of Apache's and the broader open source community's efforts was the revised Java Specification Participation Agreement (JSPA) and the JCP 2.5 process document. According to those latest JCP changes, the expert group lead has the responsibility to choose what license the specification, the RI, and the TCK are licensed with.

Changing EC politics

The JCP's embrace of the open source community transformed the dynamics not only of the JSR expert groups and the licensing of their deliverables, but also the role of the JCP executive committees. Increasingly, EC members use their voting power to enforce a more community-minded process. For instance, the EC failed to approve the community draft of JSR 116, the SIP (Session Initiation Protocol) Servlet API, due to that JSR's licensing terms. Similarly, IBM cast a 'nay' for JSR 131, ECPerf 1.1, due to licensing terms. And when a spec lead for JSR 182, the JPay API, required EC members to log in to a password-protected Website requiring agreement to proprietary license terms to gain access to specification documents, all EC members became alarmed.

Doug Lea, a computer science professor at Oswego University, is the J2EE/SE executive committee's only individual member, not representing any organization. As such, he aims to watch out for the individual Java developer not affiliated with corporations or large open source projects. "My attention and efforts have mostly been to liberalize all licensing rather than specific JSRs," notes Lea. "I think we will be seeing more JSRs based on open source projects, including greater participation in open source efforts by the major players in the JCP."

Chiefly, as a result of the open source community's increased involvement, those major JCP executive committee players are starting to see a need to mind the broader Java community's interests as well. "The issue now, with open source and community focus," notes Apache's Hunter, "is increasingly on JSR management."

Page 3 of 3

Consider the case of JSR 154, the Java Servlet Specification. "According to the JCP rules, the spec lead makes the decisions, and the expert group members are there to advise," says Hunter. "In JSR 154, there has been a consistent pattern of expert opinion going one way and the spec lead, a newly appointed Sun representative, going exactly the opposite. That's okay once in a while, but how do you build a community where the majority of the expert group, people who have been there for years and are truly the world experts [on servlets], are being second-guessed without explanation?"

When the servlet spec comes up for the executive committee's vote, will Apache's representative vote to approve it? Don't hold your breath, advises Hunter. "Apache won't support a technology that was created without community support."

Back to toasters

We started this series with a question: If you have a brilliant new idea for a Java technology or API—such as an API to interface with Java-enabled toaster ovens—how do you introduce that idea into Java? With the JCP's increasing embrace of open source ideas and processes, you might decide to propose that Java API as a JSR. As a developer with a great idea, how could you ensure your JSR's success in the JCP?

Lea advises that you first familiarize yourself with the basic requirements of JSRs: "Be aware that bringing a JSR from conception to completion may take thousands of hours and the involvement of dozens of people. It helps if you've already designed, implemented, tested, and gathered usage experience from preliminary versions."

Lea says to next contact other developers: "A JSR expert group ought to be a diverse collection of true experts, with similar goals but working in different projects, organizations, and/or companies. While it is not strictly necessary to form a tentative expert group before submitting the JSR, it is a very good idea. Otherwise the EC has a lot of trouble assessing both the need for the JSR and the ability to carry it out. As much as I like cheering on individual submitters, I have voted against a few proposals on these grounds."

As for selecting your expert group, Lea advises keeping the size manageable, with less than 10 highly talented and energetic members. "JSRs often fail when expert group members only half-heartedly participate, drop out, or were selected just for the sake of appearances and aren't really interested in the JSR," he continues.

Once you've done some preliminary design and gathered your expert group, Lea advises contacting the JCP Program Management Office (PMO), as the staff can help guide you through submission rules. He also suggests reading the Spec Lead guide, which you can download from the JCP Website. "If your JSR entails any changes in the [Java] platform itself, then the JSR needs the involvement of at least one JVM provider who can develop these aspects of the reference implementation," says Lea. "Also, it would need to be mapped out to a given J2SE, J2EE, or J2ME release."

Get involved

Our analysis of the JCP concurs with Lea's advice. Perhaps the biggest conclusion we can draw from that data is that it takes a lot of work to complete a JSR. In practical terms, to lead a successful JSR, you either should be part of a larger organization able to devote resources to your JSR-related work or, if you are part of a smaller company or an individual developer, your best route is to involve the open source developer community from the outset of your proposals. We suggest that you start an open source project and complete some releases of the code before proposing a JSR. Doing that would test not only interest in your proposal, but also your ability to effectively lead, and work with, others.

Another important finding is that community pressure does have an impact on corporate Java powerhouses. In the simplest terms, that means the future of Java technology is in your hands: Java's future depends on your ability to come up with innovative ideas and, equally, to lead other interested developers in turning your idea into a reality. The JCP is a framework for such collaborative endeavours—by itself, it neither advances Java, nor hinders its progress. Only you, the Java developer, can make Java's success last. The JCP offers you the visibility and the processes you need to make your mark on the technology's future, and you can use those tools to your advantage. So next time you feel down about Java's future, don't just stay on the sidelines: get involved. Join the JCP, contribute code to a JSR, write a few lines of documentation. While you may think that your individual contribution would be so small as to be insignificant, that is not the case: many small contributions do add up. Java's future depends on the additive power of such small contributions.

Sonali Shah is a doctoral candidate at the Massachusetts Institute of Technology conducting research on innovation communities in several industries. Frank Sommers is founder and CEO of Autospaces, a company focused on bringing Jini technology and Web services to the automotive software market.

Learn more about this topic