The Java Community Process (JCP) formalizes the international Java community's efforts to improve Java. Its goal is to cultivate a wider participation in the specification of new and existing Java APIs. (For a definition of API and other terms in this article, see Glossary.) </!> Ken Urquhart, the JCP project leader at Sun, believes Java is successful "because people have given the time and effort" to make it successful. The JCP attempts to expand on that success. In fact, Java creator James Gosling says that the process is all about "getting the managers out of the room and letting the technical people do their thing."
Sun and the JCP participants have been very happy with the results: 38 Java Specification Requests (JSRs) have been submitted since the program started ten months ago. Two to four new participants join the process every week. The first public reviews of the new specifications began in June, at JavaOne '99.
Not everyone in the Java community is as happy as Sun is with the JCP, however. Many small developers, and even some large companies, consider the process neither open nor vendor neutral. Organizations wishing to participate in the JCP must pay annual fees to Sun. Only then can they provide experts to the JCP and actively shape a specification.
In this article, I examine the Java Community Process in detail, looking at how the process works and at the issues being raised by some members of the Java community. I also note several ways you can get involved with the Java Community Process and suggest a few improvements Sun can make to it.
The Java Community Process consists of a series of steps designed to produce high-quality, widely accepted Java specifications. The formal JCP documentation (see Resources) states that those steps are taken "in cooperation with the international Java community." As JCP project leader Urquhart puts it, "Nothing can be developed in a vacuum," adding that industry involvement makes Java better and more widely accepted. Sun says that it has been using collaborative methods to develop the Java APIs since 1995 and that the JCP -- announced in December 1998 -- attempts to structure and document that collaboration and to encourage participation in it.
Simon St. Laurent disagrees. In a posting to the XML-dev mailing list, he stated, "The JCP may feel like an 'open' process if you're a mammoth ... but to us small mammals, it's the same old s***, different day." St. Laurent is not alone. Elliotte Rusty Harold, the author of several Java books and the keeper of the Café au Lait Java FAQ (see Resources), thinks the JCP "is very much a gated community designed to keep out the riff-raff like you and me and let Sun run things the way it sees fit."
The following table outlines the JCP and the length of time associated with each step of the process:
|Participant submits a new specification, or JSR||(Anytime)|
|Other participants review the JSR||7 to 30 days|
|PMO reviews comments||(Accepts, rejects, or defers JSR)|
|Call For Experts (CAFE)||At least 15 days|
|PMO selects specification lead||(Most capable person chosen from CAFE nominations)|
|Specification lead forms Expert Group||(From other CAFE nominations and other sources)|
|Expert Group writes draft||However long it takes|
|Participants review draft||At least 30 days|
|Specification lead revises draft||Up to 30 days|
|Public reviews draft||At least 30 days|
|Specification lead revises draft||Up to 30 days|
|Public release||Depends on completion of CTS and RI|
|Expert Group develops CTS and RI||(Specification lead is responsible for completion)|
|Expert Group decides that specification, CTS, and RI are complete||However long it takes|
|Final release of specification||(Everything complete)|
|Maintenance of specification||(Specification lead assumes responsibility for maintenance)|
Changing the world, one API at a time
At the heart of the Java Community Process is the Java Specification Request (JSR), which describes the proposed specification for a new set of APIs or for a change to existing Java APIs. The JSR provides information about the participants submitting the request, briefly describes the proposed specification and the reason for developing it, and notes any documentation or implementations that could be used as a starting point for the development of the new specification.
A JSR is submitted via a Java Specification Request form (see Resources), which is emailed to the Process Management Office (PMO) at Sun. Submitting the JSR is the first step in the Java Community Process, but a JSR can be submitted only by a Java Specification Participant.
Participation has its advantages -- and costs
A Java Specification Participant is a company, organization, or individual that has signed the Java Specification Participation Agreement (or JSPA; see Resources). Anyone can become a JCP participant by filling out the JSPA and sending it to Sun along with an annual fee. The fee is large enough that it may prevent the involvement of many Java community members. Here is the fee structure:
|Education, government, nonprofit organization||,000/year|
|Commercial Java technology licensees of Sun||No fee|
Once you are a participant, you are involved in the entire Java Community Process. You can comment on Java Specification Requests, provide an expert to an Expert Group, and review and comment on the Participant Draft before the public review. If you are not a participant, you cannot submit a JSR or provide feedback on other JSRs or draft specifications until the public review.
Issues with participant fees and the agreement
For many smaller companies and academic experts, the cost of becoming a participant in the Java Community Process is prohibitively high. One academic said, "To get a bunch of academics to agree to fork over ,000 a year just so they can help Sun out seems difficult and rude." Sun says it charges the annual fee simply to cover expenses associated with managing the Java Community Process. Further, Sun says it has waived participation fees in the past and will continue to do so as the need arises. Unfortunately, there is no mention of that possibility anywhere on the Web site devoted to the process.
Some companies also take issue with signing the participation agreement, balking at requirements such as the "potential surrendering of intellectual property rights." These concerns, voiced on the Web site, contributed to the creation of the J Consortium, a nonprofit organization established "to advance the creation of specifications and related activities for what we refer to as real-time and embedded extensions for Java technologies."
Submitting a specification
Once you are a Java specification participant, you can submit your Java Specification Request (JSR) to Sun's Process Management Office. The PMO will review the JSR to make sure all the information is in order and that it doesn't conflict with an existing specification or JSR. The PMO then posts the JSR to the Community Process Web site for review (see Resources).
Here there is some discrepancy between the formal JCP Manual and the information on the JCP Web site: according to the manual, JSRs will be posted to a private Web site, accessible only to participants, but in fact Sun has posted all the JSRs on its public site. Unfortunately, there is no specified way for the public to comment on the JSRs.
The PMO's review takes between a week and a month, during which time it considers comments from the participants. It then accepts or rejects the JSR. If it accepts the JSR, the PMO puts together the Expert Group to fully develop the specification.
The Expert Group
Sun believes the best way to develop a robust specification is to "start with a handful of industry experts." The Process Management Office issues a Call For Experts (CAFE) to all participants (see Resources). Any participating company can select one of its employees to be an expert in the field outlined in the JSR. The Call For Experts is open for 15 days, at which point Sun's Process Management Office selects the experts and the specification lead for the Expert Group.
The specification lead plays a key role within the Java Community Process. She or he is responsible for getting the specification written (basing it on input from the Expert Group), for producing both the Compatibility Test Suite (CTS) and the Reference Implementation (RI), and for determining when each draft is complete and how much time is needed for each review. The specification lead also makes the final decision on any unresolved issues in the Expert Group. Of the 14 Expert Groups that have been formed, eight are led by Sun employees.
An Expert Group requires a strong commitment from each member. Sun estimates that the specification-lead role requires at least 50 percent of the time of a full-time employee. Full participation for the other experts may also require as much time, depending on their involvement. Urquhart stressed the importance of the experts' commitment, saying that the cost of their time was far greater than the ,000 participation fee.
The first goal of the Expert Group is to produce the participant draft of the specification. This is the period in which the bulk of the work on the specification is done: the Expert Group hammers out APIs, drafts documents, and builds consensus. Once the draft is completed, Java specification participants review it privately.
The participant review takes at least 30 days, during which time each participant's comment is assigned a unique identification number to assure proper tracking of participant feedback. At the end of the participant review, the Expert Group gathers all comments about the specification and responds to them. The Expert Group has up to 30 days to revise the specification. The specification is then ready for public review.
Once it is ready, a public draft is posted to a public Web site for the Java community's review. The public review lasts at least 30 days, but it can take as long as the Expert Group deems necessary. Sun considers the public review to be the cornerstone of the Java Community Process and says that it has been so for every Java API developed, despite what Java developers might think. Urquhart proclaims, "The entire world has helped develop Java." But many small developers have stated loudly that they have been consistently ignored despite repeated attempts to participate in the process. To illustrate Sun's flexibility, Urquhart points to last-minute changes made to the Java Media Framework specification after a public review. The JMF was created by Sun, though, and the company directly benefited from the feedback. No specifications created by other companies have been publicly reviewed yet.
While all public comments are read and considered, they do not need to be catalogued as are the participant comments. If any comments result in major changes to the specification, the specification will be revised and re-posted to the Web site for review, along with a synopsis of the changes. Once the public review is complete, the specification lead has 30 days to revise the public draft. The final specification is then posted to the public Web site.
Once the specification is finalized, the Compatibility Test Suite (CTS) and Reference Implementation (RI) can also be completed. The Compatibility Test Suite is a suite of tests that an implementation of the specification must pass to be considered compliant with the specification. The Reference Implementation is a proof-of-concept implementation of the specification that passes the Compatibility Test Suite.
If any flaws or ambiguities in the specification are discovered while the Compatibility Test Suite or Reference Implementation is developed, the Expert Group will correct the specification and re-post it to the public Web site.
This process continues until both the CTS and RI are complete. At that point, the entire package -- including the final specification -- is posted to the public Web site.
With the final release of the specification, the Java Community Process moves into the maintenance phase. The Expert Group disbands and an interpretation guru is selected. The interpretation guru is responsible for monitoring feedback from the Java community and proposing changes to the specification. Typically, the specification lead becomes the interpretation guru. If the specification lead is unable to serve as the interpretation guru, she or he can suggest a replacement, which the PMO must accept. Alternately, the PMO may appoint a guru.
The system of appointments betrays Sun's control of the Java Community Process: The Process Management Office is staffed by Sun. It selects the specification lead (who controls the development of the specification) and approves the interpretation guru (who controls all changes to the specification).
Feedback on the specification can include clarifications and requests for major enhancements and bug fixes. All comments are logged and assigned a unique ID. The interpretation guru reviews all comments and maintains a public list of common issues and their status. From this feedback, and with the support of the original experts and the Java community, the interpretation guru proposes changes.