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 |
Experience has shown that the best way to produce a technology specification is to use an open and inclusive process to co-develop a specification and implementation, informed by a group of industry experts with a variety of viewpoints, community and public opportunities to review and comment, and a strong technical lead to ensure both the technical goals and integration with other relevant specifications and user expectations.
An Executive Committee (EC) representing a cross-section of both major stakeholders and other members of the Java community is responsible for approving the passage of Specifications through the JCP's various stages and for reconciling discrepancies between Specifications and their associated test suites.
Once you learn the overall process of the JCP, it's easy to understand where and how you might fit in and contribute. Here are several topics to help you with the procedures.
JCP 2 Procedures
On June 2, 2000, JCP 2.0 replaced the previous JCP 1.0 version for new submissions. Further refinements to the voting rules resulted in JCP 2.1, introduced on July 10, 2001. A major revision of the licensing rules for the Spec, RI and TCK as well as IP policy changes and process changes was put in place by JCP 2.5, launched on October 29, 2002. The process was revised in May 2006 with the release of JCP 2.6, and again in May 2009 with JCP 2.7. In October 2011, JCP 2.8 introduced a new set of transparency requirements for JSRs. In August 2012, JCP 2.9 introduced changes to the formation of the Executive Committee. In April 2016, JCP 2.10 introduced and defined different types of JCP Membership. The current version, JCP 2.11, both streamlined the process by removing requirements for additional review periods and introduced the ideas of iterative JSRs and Errata Maintenance Releases. The program's complete rules can be found in the JCP 2: Process Document.
The Four Major Steps in the Java Community ProcessLearn how a Java Specification Request (JSR) moves through its four essential steps to become a final specification and potentially become part of the Java platform, from the Initial Proposal to the Early Draft to the Public Draft and Maintenance.
1. Initiation (jcp.org/en/procedures/jcp2#3.3):
A specification is initiated by community members and approved for development by the Executive Committee. At times, there are new JSRs being accepted every week.
See the list of new JSRs recently submitted to the JCP here.
Definition of Terms for Submitting a New or Revised JSR
2. Draft Releases (jcp.org/en/procedures/jcp2#3.4):
Once a JSR is approved, a group of experts is formed to develop a progressive drafts of the specification that anyone with an internet connection can review. Members who have signed a JSPA and wish to nominate a representative to serve on one or more of the Expert Groups or be listed as a Contributor can do so by submitting a nomination request.
When an Expert Group completes the first draft of their specification, they will make it available to the public for Early Draft Review. The Expert Group uses the feedback from the review to revise and refine the draft.
List of current Early Draft Reviews
3. Final Release (jcp.org/en/procedures/jcp2#3.5The Expert Group uses the public feedback to further revise the document into a Proposed Final Draft. The Specification Lead then sees that the Reference Implementation and its associated Technology Compatibility Kit are completed before sending the specification to the Executive Committee for final approval. Once approved, the final Specification, Reference Implementation and Technology Compatibility Kit are published, and the Specification Lead arranges for a Maintenance Lead.
4. Maintenance (jcp.org/en/procedures/jcp2#3.6):
The Maintenance Lead tracks requests for clarification, interpretation, enhancements and revisions in an Issue Tracker. Then the Maintenance Lead initiates a review of the proposed changes. The Executive Committee votes to approve all proposed changes to a specification to be carried out immediately or reject the changes and thus either require the Maintenance Lead to submit a revised list of changes, or defer the changes until the specification can be revised by an Expert Group in a new JSR. If the Executive Committee approves the ballot, then the Maintenance Lead produces an updated Specification, Reference Implementation, and Technology Compatibility Kit as required to accommodate those approved changes. Challenges to one or more tests in a specification's Technology Compatibility Kit are ultimately decided by the Executive Committee if they cannot be otherwise resolved.
List of current Maintenance Reviews
JSR Voting Results
JSR Voting results can be seen here.
Read a quick overview on how and why the JCP was begun.
Translations/Changes between JCP versions
Understand the differences between the old and new versions of the JCP process.