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.
