 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
JCP Procedures
JCP 1: Process Document
JCP 2.11 |
JCP 2.10 |
JCP 2.9 |
JCP 2.8 |
JCP 2.7 |
JCP 2.6 |
JCP 2.5 |
JCP 2.1 |
JCP 2.0 |
JCP 1.0
The formal procedures for using Java Specification development process Version 1.0 (December 1998)
Comments to:
pmo@jcp.org
CONTENTS
Executive Summary
Sun Microsystems, Inc., is implementing a formal process for developing Java™ specifications that produces high- quality specifications in "Internet-time" using an inclusive, consensus building process that not only delivers the s pecification, but also the reference implementation and its associated suite of compatibility tests. Our experience has proven that the best way to develop a specification is to start with a handful of industry experts who have a deep understanding of the technology in question and then have a strong technical lead work with them to create a first draft. Consensus is then built using an iterative review process that allows an ever-widening audience to participate and to see their comments and suggestions incorporated into successive draft versions of the specific ation prior to its final release. The recent additions to our process have been to:
THE JAVA COMMUNITY PROCESSSM PROGRAM There are 11 steps to the Java Community Process. Each step is described in its own section below. Terms are defined in their relevant sections.
1. PROPOSE A NEW SPECIFICATION
DEFINITION - Java Specification (Specification): A written specification for a Java Application Prog ramming Interface (API). DEFINITION - Specification Development Process (Process): The formal, auditable process for developi ng Specifications that is described in this document. DEFINITION - Process Management Office (PMO): The group within Sun Microsystems, Inc. designated to oversee the development of all Specifications. DEFINITION - Java Technology Licensee (Licensee): A company, organization, or individual that has en tered into a commercial license for Java technology with Sun Microsystems, Inc. and is not in breach of that agreemen t. DEFINITION - Java Specification Participation Agreement (JSPA): A one-year, renewable, agreement bet ween Sun Microsystems, Inc. and a company, organization, or individual that allows the latter entities to participate in the Process. Licensees are required to sign a JSPA to participate in the Process. DEFINITION - Java Specification Participant (Participant): A company, organization, or individual th at has entered into a Java Specification Participation Agreement with Sun Microsystems, Inc. DEFINITION - Java Specification Request (JSR): The form submitted to the PMO by one or more Particip ants proposing the development of a new Specification. Participants can submit a request to develop a new Specification, or make a major revision to an existing one, by fil ing a Java Specification Request (JSR) with the PMO. The format of the JSR is described in Appendix A. Briefly, the J SR serves to identify the submitter, identify the other Participants who support the request (if any), describe the p roposed Specification, the reason(s) for developing it, the target Java platform(s), and any pre-existing documents, technology descriptions, or implementations that might be used as a starting point. A Participant can have up to thre e JSRs under consideration by the PMO at any given time (a JSR is defined to be under consideration from the time it is filed with the PMO up until it is either accepted for development into a Specification or rejected and returned). Any JSR that is under consideration can be withdrawn by its submitter for whatever reason upon written request to the PMO.
2. SELECTION OF A JSR FOR DEVELOPMENT
Once a JSR has been submitted, the PMO will evaluate it for completeness. The JSR will be automatically rejected by t he PMO if the JSR:
The PMO will inform the submitter of the specific reason(s) for rejection. The submitter has the option of amending t he JSR to address the problem(s) and then re-filing it with the PMO. The PMO will post all other JSRs to the Participant Web Site for JSR Review. DEFINITION - Participant Web Site: The designated Sun web site that is accessible only to Participan ts. It serves to disseminate information of interest to Participants and to gather their feedback. DEFINITION - JSR Review: A period of at least 7 days but no more than 30 days during which time the JSR is posted at the Participant Web Site for review and comment by all Participants. At the end of JSR Review, the PMO will review the comments received and decide whether to accept the JSR for developm ent, reject it, or defer a final decision while more information is gathered from the submitter(s), other Participant s, and/or experts in the technology in question.
DEFINITION - Expert: An active practitioner who has expert knowledge in the technology area covered by a JSR and is a full-time employee of a Participant. These are typically senior engineers engaged in product design and development who have been involved in designing and building products that are closely related to the Specificat ion. DEFINITION - Expert Group: The group of Experts who develop a Specification using the Process. There will generally be no more than one Expert from a given Participant on the Expert Group. DEFINITION - Specification Lead: The Expert responsible for writing the Specification with input fro m the other Experts, and hence responsible for developing consensus within the group. This person must possess strong diplomatic and writing skills as well as technical expertise. The actions of the Expert Group are coordinated by the Specification Lead - the Expert responsible for writing the Sp ecification with input from the other members of the Expert Group. He or she will ultimately be responsible for devel oping and maintaining consensus within the group as well as rendering tie-breaking decisions based on his or her tech nical and design knowledge when general consensus cannot be reached. The PMO forms the Expert Group by issuing a "CAll For Experts" (CAFE) to all Participants. The CAFE asks Participants who wish to volunteer one of their employees to serve on the Expert Group to identify both themselves and their expe rt to the PMO. These Participants must provide the PMO with:
The CAFE will be open for at least 15 days. When the CAFE closes, the PMO will evaluate the qualifications of the pro posed Experts and select a Specification Lead from among them. This person need not be a Sun engineer. DEFINITION - Reference Implementation (RI): The "proof of concept" implementation of the Specificati on that will be made available by Sun Microsystems, Inc. The Participant whose Expert is chosen as Specification Lead is typically responsible for producing the RI. DEFINITION - Compatibility Test Suite (CTS): The suite of tests and requirements that an implementat ion of the Specification must pass in order to be considered compliant with the Specification. The Participant whose Expert is chosen as Specification Lead is typically responsible for producing the CTS. It's important to note that the Participant whose Expert is the Specification Lead typically assumes the responsibili ty of producing, maintaining and licensing both the Reference Implementation (RI) and its associated Compatibility Te st Suite (CTS). Note that the Participant who is responsible for the RI and CTS does not necessarily have to produce these items pers onally. The responsible Participant can arrange to produce the RI and/or CTS in cooperation with other Participants w ho have contributed Experts to the Expert Group or delegate that task completely to one or more of these Participants . Once chosen, the first duty of the Specification Lead is to select the other members of the Expert Group from the rem aining list of nominees based on both their qualifications and on the need to preserve diversity of opinion within th e group. While there is no specific limit on the size of an Expert Group, experience has shown that smaller groups ar e usually more effective. It is possible that the Specification Lead may feel it essential to include experts from Participants who did not res pond to the CAFE. In this case, the Specification Lead may approach these Participants and try to work with them to i dentify their expert and bring them into the Expert Group. The Specification Lead can also add additional Experts lat er in the Process if he or she can justify to the PMO that they would significantly enhance the technical quality of the Specification. The PMO can also elect to add a Sun Expert to the Expert Group at any time during the Process (pro vided one is not already in the group). Participants who responded to the CAFE but were not selected to serve on the Expert Group possess focussed expertise and skills that may be of considerable use to the Expert Group during the Process. The Expert Group will therefore re tain the complete list of CAFE respondents so they can call upon some or all of the respondents as needed to help the Expert Group understand and/or resolve specific technology issues. Once the Expert Group has been formed, the Independent Auditor will carry out the first Milestone Audit of the Proces s. After any auditing anomalies have been corrected, the Experts must attend a "kick-off" meeting held by Sun Microsy stems' Java Software Division. This meeting will serve to introduce the Experts to one another, give them an understa nding about how the Process will proceed, and provide them with audit training so that all Experts will understand wh at they must do to maintain auditability. DEFINITION - Independent Auditor: The external company designated by Sun to be responsible for audit ing each use of the Process.
4. WORKING WITHIN THE EXPERT GROUP
Each Expert Group is free to define and follow whatever working style it finds most productive and appropriate (subje ct to the auditing requirements of the Independent Auditor). However, experience gained from carrying out more than 3 0 successful Specifications projects using the Process has shown that the most straightforward and consistently succe ssful approach to producing high-quality Specifications in a timely manner is for the Specification Lead to gather mo st of the technical information and input from each Expert in a pair-wise fashion while writing and revising the Spec ification. As this information is incorporated the Specification Lead should frequently distribute updated versions o f the Specification to the Experts for all to see. E-mail exchanges within a private mailing list established for the exclusive use by the Expert Group, along with conf erence calls and group meetings, are then used to discuss and resolve issues raised by the Experts as they review the evolving contents of the document. Note that in-person group meetings should perhaps be used sparingly as they tend to slow the Process down considerably due to the need to coordinate schedules. It is recognized that an Expert may withdraw from the Expert Group during the Process. In this case, the Specificatio n Lead will approach the Participant who originally contributed the Expert and work with them to find a replacement. If no replacement can be found, the Specification Lead should recruit the replacement from among the original group o f Participants who responded to the CAFE but were not selected for the Expert Group. If that fails, the Specification Lead, in consultation with (and approval of) the PMO, can try to recruit a replacement from Participants who did not respond to the CAFE. If the departing Expert is the Specification Lead, a new Specification Lead will be recruited b y the PMO after consultation with the remaining members of the Expert Group. There may be instances where members of the Expert Group feel that one or more of their fellow Experts are not acting in ways that advance the work of the Expert Group. These concerns should be brought to the attention of the Specific ation Lead and/or the PMO so quickly as possible so they can be proactively addressed and resolved.
5. WRITE THE PARTICIPANT DRAFT
DEFINITION - Participant Draft: The first draft of the Specification that the Specification Lead, in consultation with the other Experts, prepares for review by Participants. The Expert Group begins work by considering the requirements set forth in the JSR, any pre-existing documents, techno logy descriptions, or implementations identified in the JSR, the comments received from Participants during JSR Revie w and, if this is a revision of an existing Specification, the Change Log kept by the Interpretation Guru (see sectio n 11, Maintenance, for details). Additional input should then be obtained from the Java community by having discussio ns with other Participants, industry groups, software developers, end-users, and academics. The intent is to gather a s much information as possible from those with expertise and a material interest in the technology. The goal of this step is to define requirements and then produce a draft of the Specification that is suitable for review and comment by the Participants. When the Specification Lead, in consultation with the other Experts, decides that the Participant Draft is ready for distribution, the Specification Lead will notify the PMO to initiate the associated Milestone Audit. Any auditing ano malies must be corrected before Participant Review can begin. The Experts are encouraged to carry out prototype engineering work while writing the Participant Draft. This work wil l serve to solidify the concepts and ideas that are being incorporated into the draft.
6. REVIEW AND REFINE THE PARTICIPANT DRAFT
DEFINITION - Participant Review: A period lasting at least 30 days during which Participants can rev iew and comment on the original Participant Draft and any revisions issued by the Expert Group during this time. The iterative refinement of the Specification begins when the Participant Draft is distributed to Participants for Pa rticipant Review. The goal of Participant Review is to get the Specification draft into a form suitable for Public Re view quickly. The review period must be at least 30 days. The precise number of days is set by the Specification Lead (in consultation with the other Experts) and is ultimately determined by the number and the type of Participant comm ents balanced against the need to complete the Participant Review in a reasonable period of time. All Participant comments will be assigned a unique identification number. The Specification Lead is responsible for e nsuring that all Participant comments are considered and responded to. Responses to similar comments from multiple Pa rticipants may be responded to as one. The Participant Draft may be revised based on comments from Participants. If, in the general opinion of the Expert Gr oup, those revisions result in major changes, the Specification Lead will arrange for a revised Participant Draft (al ong with a synopsis of the changes made) to be re-circulated to the Participants. This posting of revised Participant Drafts may be repeated as necessary throughout the Participant review period. Following the end of Participant Review, the Specification Lead will have up to 30 more days to make any final revisi ons to the Participant Draft in preparation for the next Milestone Audit. At this point, the Specification should be in good enough shape for the Participant responsible for the RI and CTS to develop an implementation project schedule and begin work. In general, the Reference Implementation shall:
DEFINITION - Public Review: A period lasting for at least 30 days during which time the general publ ic can review and comment on the original Public Draft and any subsequent revisions issued by the Expert Group. DEFINITION - Public Web Site: Sun's public web site where Java Specifications are available for down load. The URL for this site is http://java.sun.com. DEFINITION - Public Draft: The refined and improved draft of the Specification that the Expert Group prepares for Public Review. Upon successful completion of the Milestone Audit, the Specification is promoted to Public Draft and is published on the Public Web Site for Public Review. In keeping with the goal of web-wide participation, anyone with access to the Internet can download and comment on the Public Draft of the Specification. Like Participant Review, Public Review wi ll last for at least 30 days. The precise number of days is set by the Specification Lead, in consultation with the o ther Experts, and is ultimately determined by the number and the type of Public comments balanced against the need to complete the Public Review in a reasonable period of time. Public Review is a critical part of the development process. In the past, comments from the public have raised fundam ental architectural and technology issues (missed by both the Expert Group and Participant Review) that have consider ably improved Java Specifications. The Specification Lead is responsible for ensuring that all Public comments are read and considered. If those comment s result in revisions to the Public Draft, and those revisions result in major changes (in the general opinion of the Experts), then the Specification Lead will arrange for the revised Public Draft, along with synopses of the changes made, to be re-posted to the Public Web Site. Following the end of Public Review, the Specification Lead will have up to 30 more days to complete any final changes to the Public Draft in preparation for the next Milestone Audit. On or before the end of the 30 days, the Specificat ion Lead will inform the PMO that the Public Draft is complete so the PMO can initiate the associated Milestone Audit . Any auditing anomalies must be corrected before the First Public Release of the Specification.
Upon successful completion of the Milestone Audit, the Specification is made available for download at the Public Web Site. It is possible that the Reference Implementation and Compatibility Test Suite may uncover areas of the Specification that were under-defined, incomplete, or ambiguous. The Specification Lead, in consultation with the responsible Parti cipant and the other members of the Expert Group, will correct any deficiencies in the Specification that may be unco vered. If changes are necessary, the Specification Lead will arrange to re-post the revised Specification, along with synopses of the changes made, at the Public Web Site at least once a month while the RI and CTS are being developed. Public comments on the corrections will be accepted and considered by the Specification Lead as per the process used during Public Review. The Specification Lead will promptly report any delays in the RI/CTS project schedule to the PMO and provide an updat ed project schedule along with each such report. Excessive problems or delays in the completion of either the RI or C TS may result in the PMO reassigning these tasks to another Participant who is better able to complete them. In this latter case, the PMO may also need to appoint a new Specification Lead for the remainder of the Process. When the Specification Lead, in consultation with the other Experts and the PMO, is satisfied that the CTS provides a dequate test coverage, the RI adequately implements the Specification, and the RI passes the CTS, the Specification L ead will inform the PMO that the Process is complete. The PMO will then initiate the Final Audit. Any auditing anomal ies must be corrected before the Specification can be promoted to Final Release. DEFINITION - Final Audit: The audit of the entire Specification Development Process that is carried out by the Independent Auditor prior to Final Release of the Specification. The Final Audit report will be posted on a 3rd party web site that is not under the control or influence of either Su n Microsystems, Inc. or the Independent Auditor.
The PMO will arrange for the completed Specification to be placed on the Public Web Site. Upon Final Release, the Exp ert Group will have completed its work and disbands.
The Interpretation Guru handles maintenance of the Specification. The Specification Lead will take on this role at th e time of Final Release. This is one of the duties that both the Specification Lead, and his or her organization, agr ees to as a condition of being appointed to the role. Every released Specification must have an assigned Interpretati on Guru and it is the responsibility of the Interpretation Guru, in consultation with (and approval of) the PMO, to r ecruit a replacement if he or she is unable or unwilling to either take on this responsibility or to continue with th is responsibility going forward. The replacement should be recruited from one of the Participants who contributed an Expert to the former Expert Group or, with the approval of the PMO, from one of the other Participants. In exceptiona l cases, the PMO may choose to appoint a new Interpretation Guru when the departing Interpretation Guru is unable to locate a suitable replacement.
The Interpretation Guru is responsible for drafting proposed changes to the Specification in response to requests for clarification, interpretation, enhancements, and changes that are received from Participants and the public via the designated e-mail address published with the Final Release. All such requests will be assigned unique identifying ref erence numbers and logged. The Interpretation Guru will review all comments, identify common themes, and maintain a p ublic list of frequently raised issues and their status. The Interpretation Guru is free to consult with the former members of the Expert Group, or any other source, for inpu t on how to revise the Specification in view of the issues raised in the requests. All such changes proposed by the I nterpretation Guru will make their way into the Specification by either the lightweight maintenance process defined b elow or by the full Process when a major revision to the Specification takes place. DEFINITION - Change Log: A public document available on the Public Web Site that lists all revisions made to the Specification by the Interpretation Guru during Maintenance. There are three sections: proposed (revisio ns not yet integrated into the Specification), accepted (revisions that have been made), and deferred (revisions held over for consideration by a future Expert Group formed to carry out a major revision using the Process). The lightweight process runs as follows: the Interpretation Guru will log all proposed changes in the "Proposed" sect ion of the Specification's public Change Log. Such changes should be consistent with the public list of frequently ra ised issues. An e-mail notification of the proposed changes will be sent to all Participants and anyone else who has signed up to be notified of changes to the Specification (sign-up is accomplished using an electronic form that will be made available at the Public Web Site upon Final Release of the Specification). Comments on proposed changes will be accepted from Participants and the public for at least 30 days and logged on the public comment list. If, at the end of that time, no strong opposition has been expressed by a majority of the Parti cipants or the PMO, the Interpretation Guru will make the proposed changes to the Specification (with due considerati on to the comments received), document the changes in the "accepted" section of the Change Log, and then delete the c orresponding entries in the "proposed" section of the log. All proposed changes that are not incorporated into the Sp ecification, or judged by the Interpretation Guru to constitute a major revision that should be made using the Proces s, will be moved from the "proposed" section to the "deferred" section of the log. Whenever the Specification is revised, the Interpretation Guru will be responsible for reviewing the current CTS to d etermine what tests (if any) need to be revised and then make sure those revisions are carried out. The CTS is an int egral and critical part of any Specification and the Interpretation Guru is encouraged to augment the CTS to increase its coverage even if no revisions have been made to the Specification. Naturally, whenever there are revisions to ei ther the Specification or the CTS, the Interpretation Guru will be responsible for updating the Reference Implementat ion to make sure it continues to pass the CTS and stays synchronized with the Specification. When a major revision is made to the Specification by the Process, the Change Log will be made available to the new E xpert Group so they can consider all the changes that were placed into the "deferred" section. Interpretation Guru may be replaced when the Specification is superceded by the major revision since the Process allo ws for the appointment of a new Interpretation Guru at the time of Final Release of the revision.
APPENDIX A: Java Specification Request (JSR) Format
A JSR must conform to the following general outline and contain at least the following information: Section 1. Identification
Section 2: Request
Section 3: Contributions
|
