Find JSRs
Submit this Search


Ad Banner
 
 
 
 

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
Copyright (c) 1996 - 2012 Oracle America, Inc.

CONTENTS

Executive Summary
1. Propose a New Specification
2. Selection of a JSR for Development
3. Form the Expert Group
4. Working Within the Expert Group
5. Write the Participant Draft
6. Review and Refine the Participant Draft
7. Public Review
8. First Public Release
9. Final Release
10. Interpretation Guru
11. Maintenance
Appendix A: Java Specification Request (JSR) Format


THE JAVA COMMUNITY PROCESSSM PROGRAM

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:

  • Refine and formalize the steps,

  • Allow companies, organizations, and individuals who have not licensed Java technology from Sun Microsystems to fo rmally participate in the Specification development process,

  • Enable companies, organizations, and consortia to use this process for developing Java specifications with or wit hout the direct involvement of Sun Microsystems, Inc. engineers.

  • Have an independent auditing firm review the process at key milestones to uncover and correct any anomalies befor e they become a problem,

  • Have the independent auditor carry out a final, overall, audit at the end of the process and then issue a final p ublic report at a 3rd party web-site not under the control of either Sun or the auditor,

  • Require a reference implementation and the associated suite of conformance tests to be developed along with the s pecification.
These new procedures are designed to allow for wider participation in the early stages of specification development a nd to provide an extra level of assurance to the international Java community that all steps of the process have been properly carried out by all parties involved and that a given specification can be implemented and tested for confor mance.

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 SPECIFICATIONReturn to Top

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 DEVELOPMENTReturn to Top

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:

  • Does not provide all of the requested information (see Appendix A).

  • Conflicts with, or substantially duplicates, a Specification that is currently under development.

  • Conflicts with, or substantially duplicates, an existing Specification.

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.

3. FORM THE EXPERT GROUPReturn to Top

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:

  • A summary of how the Participant has used or developed the technology in question.

  • The name of the employee the Participant proposes to contribute to the Expert Group, and

  • The qualifications and biographical information of that employee.

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 GROUPReturn to Top

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 DRAFTReturn to Top

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 DRAFTReturn to Top

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:

  • Be written in the Java programming language as much as possible,

  • Be as platform-independent as possible,

  • Make as much use of existing Java core classes as possible, and

  • Not utilize any private classes and methods defined inside those core classes.
On or before the end of the 30 days, the Specification Lead will inform the PMO that the Participant Draft is complet e and submit the RI/CTS project schedule to the PMO. The PMO will then initiate the Milestone Audit. Any auditing ano malies must be corrected before the Public Review period can begin.

7. PUBLIC REVIEWReturn to Top

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.

8. FIRST PUBLIC RELEASEReturn to Top

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.

9. FINAL RELEASEReturn to Top

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.

10. INTERPRETATION GURUReturn to Top

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.

11. MAINTENANCEReturn to Top

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) FormatReturn to Top

A JSR must conform to the following general outline and contain at least the following information:

Section 1. Identification

  • The names and contact information of the Participants submitting the JSR.

  • An optional list of other Participants who endorse the JSR.

Section 2: Request

  • The target Java platform (i.e., desktop, server, personal, embedded, card, etc.).

  • The need of the Java community this work addresses.

  • An explanation of why the need isn't met by existing specifications.
  • The Specification to be developed and how it addresses the need.

  • Detailed description of the underlying technology or technologies.

  • Proposed package name for API Specification (i.e., javax.something, org.something, etc.).
  • Possible platform dependencies (such as an anticipated need for native code).

  • Security implications.

  • Internationalization implications.

  • Localization implications.

  • Risk assessment (impact of work on target platform, impact if work not carried out, difficulties in carrying out RI and/or CTS).
  • Existing specifications that might be rendered obsolete or deprecated by this work.

  • Existing specifications that might need revisions as a result of this work.

Section 3: Contributions

  • Detailed list of existing documents, specifications, or implementations that describe the technology.

  • Explanation of how these items might be used as a starting point for the work.