Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 387: Streamline the JCP Program

Updates to the Original JSR

The following information has been updated from the original proposal:

Having created JCP 2.11, JSR 387 has now moved to JCP 2.11 in Maintenance.


2.12 Please describe the anticipated schedule for the development of this specification.

JSR submittal: June 2018
Early Draft Review: September 2018
Public Draft Review: October 2018
Proposed Final Draft: October 2018
Final Approval Ballot: November 2018

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Heather VanCura

E-Mail Address:

Telephone Number: +1 408 276 6063

Fax Number: +1 408 276 6063

Specification Lead Member: Oracle

Specification Lead: Heather VanCura

E-Mail Addresses:

Telephone Numbers: +1 408 276 6063

Fax Number: +1 408 276 6063

Initial Expert Group Membership:

The initial Expert Group consists of all members of the JCP Executive Committee. At the time of writing these are:

Alibaba, Andres Almiray, ARM, Azul Systems, Credit Suisse, Eclipse Foundation, Fujitsu, Gemalto M2M, Goldman Sachs, Hazelcast, Hewlett Packard Enterprise, Ivar Grimstad, IBM, Intel, JetBrains, London Java Community, MicroDoc, Oracle, Red Hat, SAP, Software AG, SouJava, Tomitribe, Twitter, V2COM.

Supporting this JSR:

All members of the JCP Executive Committees support this JSR.

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR will make changes to the Process Document with the goals of further streamlining the organization's processes, modifying text to reflect the current methodology of software development, and clarifying language to reduce ambiguity.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The updated version of the Process Document will apply to all new JSRs commenced after its completion and to future Maintenance Releases of existing JSRs. The Executive Committee intends to strongly encourage - though it cannot require - that it should also be adopted by in-progress JSRs.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This JSR will address all Java platform editions.

2.4 What need of the Java community will be addressed by the proposed specification?

The primary focus of the JSR will be on streamlining the JCP program to reflect the current reality of development work happening in open source projects, with a code first, continuous delivery focus, including the JSR life cycle and milestones currently part of the JCP program. The JSR will implement changes that will build on the reforms that began with JSR 348 and continued with JSR 364, making the work of the JCP more open and transparent, and enabling broad participation.

Items for discussion include:

  • Modification and addition of language around code first, collaborative RI development.

  • Changes to the stages of a JSR lifecycle as a result of the collaborative development process (see section 3.3, 3.4, 3.5 of the Process document) and the ability to allow multiple final releases of a JSR or automated renewal for Java Platform JSRs.

  • Modifications to Renewal Ballots and Dormant JSRs.

  • Changes to the Maintenance process.

  • Changes to the size, scope and responsibilities of the JCP Executive Committee (see section 3.7 of the Process document).

2.5 Why isn't this need met by existing specifications?

See above.

2.6 Please give a short description of the underlying technology or technologies:

Not applicable.

2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

Not applicable.

2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

Not applicable.

2.9 Are there any security issues that cannot be addressed by the current security model?

Not applicable.

2.10 Are there any internationalization or localization issues?

Not applicable.

2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

This JSR will produce new versions of the JCP Process document and (if necessary) the EC Standing Rules. As explained in section 2.2 the new version of the Process Document will not replace the existing one but they will deprecate it. Any new version of the Standing Rules will immediately replace the existing version.

2.12 Please describe the anticipated schedule for the development of this specification.

JSR submittal: June 2018
Early Draft Review: September 2018
Public Draft Review: December 2018
Proposed Final Draft: February 2019
Final Approval Ballot: March 2019

This information has been updated from this original proposal:

JSR submittal: June 2018
Early Draft Review: September 2018
Public Draft Review: October 2018
Proposed Final Draft: October 2018
Final Approval Ballot: November 2018

2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.

The EC will form the Expert Group for this JSR. The Chair of the JCP will act as Spec Lead and the PMO will provide administrative assistance as necessary. In addition to working on this JSR during regularly-scheduled EC meetings, additional teleconferences will be scheduled as necessary. Since it is likely that only a subset of EC members will attend these additional meetings, their results will be reported back to the full Executive Committees for review and approval. In addition to teleconferences and face-to-face meetings, the Expert Group will make extensive use of email and collaborative tools such as a Wiki and issue-tracker, as explained in the next section.

2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

A GitHub project will host all communication mechanisms. The home-page of this project will contain pointers to the mailing-lists, Wiki, document archive, discussion forum, and issue tracker, and will explain how members of the public can observe and participate in the activities of the Expert Group.

  • Is the schedule for the JSR publicly available, current, and updated regularly?

    The document archive will contain a copy of the schedule, which will be updated as necessary.

  • Can the public read and/or write to a wiki for the JSR?

    We will use the Wiki as a one-way channel of communication (from the EG to the public.) The public will be able to read all our documents, and to respond with comments via the public mailing-list.

  • Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?

    We will provide a discussion forum, but the experience of earlier JSRs suggests that the public would prefer to use a mailing-list:

  • Have you spoken at conferences and events about the JSR recently?

    Not yet, but as with previous JSRs this will be a major topic whenever members of the PMO speak at conferences and meet with Java User Groups.

  • Are you using open-source processes for the development of the RI and/or the TCK?

    Not applicable.

  • What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?

    The standard GitHub Terms of Use will apply.

  • Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?

    It will point to the project home-page for the JSR, which will in turn provide all necessary information about the communication mechanisms used by the Expert Group.

2.15 Please describe how the RI and TCK will be delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Since this is a Process-change JSR no RI will be produced. However, according to the requirements of JCP 2.10 a JSR Review and Evaluation form will be developed. This form will enable the EC to verify that new requirements specified in the Process Document have been implemented correctly.

2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

Not applicable.

2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Not applicable.

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

The Expert Group will conduct business on a public mailing list.

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

A GitHub issue tracker will be used. The public will be able to log issues directly into the issue-tracker.

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

All documents will be archived on the JSR GitHub project page.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

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

The documents referenced above describe the current structure and operation of the JCP and form the basis for evolving the rules of the community.