The Java Community Process (JCP) Program is the process by which the international Java community standardizes and ratifies specifications for Java technologies. The JCP is designed to produce high-quality specifications through an inclusive, consensus-based model that brings together community review, expert input, and strong technical leadership.

Specifications approved through the JCP are accompanied by a Reference Implementation to prove the specification can be implemented, and a Technology Compatibility Kit (TCK) to test whether implementations comply with the specification. The Executive Committee (EC) guides a specification through each formal stage of the process and helps reconcile any issues between a specification and its associated test suite.

Once you understand the overall JCP flow, it becomes much easier to see where and how you can fit in and contribute.

JCP 2 Procedures

The JCP has evolved through multiple revisions, each refining the process, voting rules, membership model, transparency requirements, and licensing expectations for the specification, RI, and TCK.

Version	Date	Highlights
JCP 2.11	December 17, 2018	Streamlined review requirements and introduced iterative JSRs and Errata Maintenance Releases.
JCP 2.10	March 21, 2016	Defined different types of JCP Membership.
JCP 2.9	August 15, 2012	Changed the structure and formation of the Executive Committee.
JCP 2.8	October 18, 2011	Introduced additional transparency requirements for JSRs.
JCP 2.7	May 15, 2009	Updated the process after the JCP 2.6 revision.
JCP 2.6	March 9, 2004	Revised process details and clarified operating rules.
JCP 2.5	October 29, 2002	Updated licensing rules and introduced major IP and process changes.
JCP 2.1	July 10, 2001	Refined the JCP 2.0 voting rules.
JCP 2.0	June 2, 2000	Replaced JCP 1.0 for new submissions.
JCP 1.0	December 1998	Original process model for the Java Community Process.

The complete current rules are available in the JCP 2: Process Document.

JSR Life Cycle

The life cycle below summarizes how a Java Specification Request progresses from proposal to final release and then into long-term maintenance.

JSR life cycle overview

The Four Major Steps in the Java Community Process

Learn how a Java Specification Request (JSR) moves through its core stages, from initial proposal to long-term maintenance.

- A specification begins when community members submit a new or revised JSR for review. The Executive Committee evaluates the proposal and decides whether it should proceed into development.
  
  New JSRs are posted for JSR Review for two or four weeks so the public can comment on both the technical direction and the associated business or licensing terms. That review is followed by a JSR Approval Ballot, where the Executive Committee votes to approve or reject the proposal.
  
  To get started, learn the language of the JCP procedures, review the JSR Proposal form, and see the list of recently submitted JSRs.
- Once a JSR is approved, an Expert Group is formed to develop the specification through progressive drafts. Members who have signed the JSPA may nominate representatives to join Expert Groups or be listed as Contributors.
  
  The first public checkpoint is the Early Draft Review, where the Expert Group gathers feedback and refines the document. After that, the specification advances to Public Review, followed by a Public Review Ballot in which the Executive Committee decides whether the draft is ready to move forward.
  
  Browse the current Early Draft Reviews and Public Reviews to see active work in this stage.
- After public feedback is incorporated, the Expert Group prepares a Proposed Final Draft. The Specification Lead also ensures that the Reference Implementation and Technology Compatibility Kit are completed and ready for final evaluation.
  
  The Executive Committee then votes on whether the specification is ready for final release. If approved, the final Specification, RI, and TCK are published, and responsibility transitions to a Maintenance Lead.
  
  See the current Proposed Final Drafts and Final Releases.
- Once a specification is final, the Maintenance Lead tracks requests for clarification, interpretation, enhancement, and revision in an Issue Tracker. Proposed changes are then reviewed and voted on by the Executive Committee.
  
  If approved, the Maintenance Lead updates the Specification, RI, and TCK to reflect the accepted changes. Challenges to one or more TCK tests may ultimately be escalated to the Executive Committee if they cannot be resolved by other means.
  
  Review the current Maintenance Reviews to follow work in this stage.

Additional Resources

Voting Results

See how Executive Committee ballots have resolved across the lifecycle of JSRs.

View JSR voting results

JCP Background

Read a concise explanation of how and why the Java Community Process was created.

Read the JCP background overview

Translations and Version Changes

Understand the differences between older and newer versions of the JCP process.

Compare JCP versions