The Java Community Process, or JCP, was formed by Sun in 1998 in response to the community's wish to get involved with the future development of Java. Much has been written regarding JCP, and much confusion exists regarding the whole process and just exactly how much control and influence Sun has over it.
Recently I had the pleasure of meeting with Onno Kluyt, the director of the Java Community Process, who kindly took me through the whole process and answered my questions, which were mostly from some of the misconceptions that run rife in many a newsgroup and mailing list.
Fundamental to the whole program are the members. Members fall into three categories: commercial, government or educational institutes, and individual members. There is a registration fee associated with membership to cover costs, but it's free for individuals and Java licensees. At the time of writing there are approximately 660 members, of which some 220 are individuals. The members hold an election once a year (October/November) to elect two executive committees (EC), one to look after J2EE/J2SE and the other to look after J2ME. Each EC is made up of 16 members, including a permanent seat held by Sun.
This leaves 15 electable seats, of which the five oldest sitting seats are put up for reelection once a year. Once elected the members are "in office" for at least three years. Only JCP members can vote for the EC members and there are no rules as to how many "terms" a member can serve. This is as close to politics as the JCP gets, including the ability for JCP members to put themselves up for election, write a manifesto, and begin lobbying members for their votes. Sun does not manage this voting but hires PricewaterhouseCoopers to manage the whole process, and the five new members are announced during the first week of December.
The EC is responsible for managing the whole JSR process including the approval of new JSRs and ensuring each JSR goes through all the necessary steps, from initial conception to final approval, and possible absorption into the core Java editions. Another important role of the EC is to ensure that no JSR overlaps with any functionality already provided by existing Java libraries or by JSRs already in existence.
One or more JCP members can propose a Java Specification Request (JSR). This JSR can be a completely new specification proposal or a significant revision of an existing one. Once submitted, the EC will approve, or deny, the request within 14 days. They want to ensure that the JSR does indeed fit within the bounds of the JCP process and doesn't overlap with any existing JSR or specification. The person submitting the proposal becomes the specification lead who, for all intents and purposes, is the manager of the JSR.
After the JSR has been approved, the spec lead must form an expert group, which is composed of those who are experts in the field proposed by the JSR. The size of this group can be from 6 to 60 members. The expert group's first job is to prepare the community draft of the specification. All members of the JCP can see this draft and channel feedback to the expert group. The community draft goes into review for 30-90 days, and afterward the EC votes on whether or not the JSR is strong enough to go into public draft.
The public draft is posted on the Internet for anyone to review and comment on. The spec lead will ensure that the necessary Reference Implementation (RI) and Technology Compatibility Kits (TCK) are available and continually kept up to date. The JSR can stay in the public draft phase for 30-90 days where it's then prepared to be presented to the EC for their final decision, which is achieved through a vote taking no more than 14 days.
If the JSR is successful, it's then taken into the maintenance phase, where the spec lead will keep all the components up to date and continually feed information back to the EC.
There's a lot going on here, and the whole process is designed to make sure that everything is kept as fair as possible without the ability to introduce any sort of old-boys network that could ultimately stifle innovation. The ownership of the final specification can now be licensed under an open-source model should the expert group deem it necessary. However, under the new rules of the JCP, anyone is free to implement the specification as long as they license the TCK for compatibility.
For more information on the whole JCP process, visit www.jcp.org.
When not answering your e-mails and working on the next issue of JDJ, Alan heads up a small team dubbed the "Thunderbirds of the Java industry," providing on- and offsite rescue for Java projects in trouble. For more information visit www.javaSOS.com.
You can also read his blog: http://alan.blog-city.com.