Maintenance Lead: Patrick Curran

E-Mail Address: patrick@jcp.org

Telephone Number: -

Fax Number: -/P>

2005.07.28:

Maintenance Lead: Onno Kluyt

E-Mail Address: onno@jcp.org

Telephone Number: +1 650 352 4752

Fax Number: +1 585 385 8754

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc

Name of Contact Person: Aaron Williams

E-Mail Address: aaron@jcp.org

Telephone Number: +1 510 550 7154

Fax Number: +1 510 550 7154

Specification Lead: Aaron Williams

E-Mail Address: aaron@jcp.org

Telephone Number: +1 510 550 7154

Fax Number: +1 510 550 7154

Initial Expert Group Membership:

The Expert Group will consist of the Members of the two JCP Executive Committees. See http://jcp.org/participation/committee/.

Supporting this JSR:

The Members of the two JCP Executive Committees ( http://jcp.org/participation/committee/) are supporting this JSR submission.

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR aims to define a new version of the Java Community Process and to address a group of specific process issues that have been observed by the the Program Office and the Executive Committees of the JCP since the completion of JSRs 99 and 171. These pragmatic changes are designed to address some of the day-to-day issues of Spec Leads and Expert Groups through relatively minor, easy to implement changes to the process.

None of these changes require any changes to the participation agreements (the JSPA or IEPA). The community is still in a transition phase to the new JSPA 2 from JSR 99, so it is not an appropriate time to consider making changes to the process that require changing these agreements further.

This JSR will not consider any issues that are difficult to implement or that require changes to the JSPA. This is a list of the specific issues that this JSR will consider:
1) Some JSRs may need to span Editions and therefore span the ECs. This JSR will consider defining when that is possible, and how that works.
2) JSRs should be more transparent to the community, and it should be easier to tell when a JSR is working and when it is dormant. This JSR will consider requiring Spec Leads to provide a status report to the PMO on a regular basis, which would be posted to the web site for community member viewing.
3) There is value to the Spec Leads to have two classes of Expert Group members - active members and observers. This JSR will consider ways to enable observer memberships to Expert Groups.
4) This JSR would also consider giving Executive Committee members the right to assign a member as an observer to the expert group for any JSR that is assigned to the EC on which they serve.
5) There is a mistake in the process document with regards to super-majority voting. This JSR would change the process from requiring super majority ballots to J2SE umbrella JSRs that propose language changes to requiring super majority ballots on any JSRs that propose language changes.
6) In order to promote more feedback at the review periods, this JSR will consider changing Community Review to Early Draft Review and making it open to the public. Also, this JSR will consider removing the Community Review Ballot and replacing it with a ballot after the second public review, called Public Review Ballot.
7) This JSR will consider setting minimum requirements for TCKs.
8) This JSR will also consider requiring spec leads to deliver a TCK Coverage Document that will enable EC members to judge the sufficiency of a TCK.
9) This JSR will consider moving the disclosure of TCK and other business terms to a point earlier in the process.

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

Not applicable.

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

The Program Office and the Executive Committees have engaged former and current Spec Leads, Expert Group Members and members of the community to identify the issues for consideration by this JSR. The changes being considered will address several immediate needs in the community, with the most important being to create more transparency in the process and in the Expert Groups. These changes will also enable JSRs to have more effective interactions with external groups, and will help improve the completion rate of JSRs.

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

See 2.1 and 2.3.

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

Not applicable.

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

Not applicable.

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

Not applicable.

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

Not applicable.

2.9 Are there any internationalization or localization issues?

It is the goal of this JSR not to introduce any aspects in the JCP Program that would hinder the current successful international participation in the process.

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

The output of this JSR will become the active working model of the Community, replacing the current process rules of JCP 2.5.

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

Community Review: July 2003
Public Review: September 2003
Proposed Final Draft: October 2003
Final Approval: November 2003

The Program Office and the Executive Committees recognize the importance of these proposed changes and we will do everything we can to maximize the involvement of the community and public at the review periods of this JSR.

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

The two Executive Committees together form the Expert Group for this JSR, with the JCP PMO as the Spec Lead. The PMO will setup a working group for this JSR, with all EC members welcome to participate. That working group will create draft versions of the new process document via frequent conference calls as well as exchange and discussion via email. The working group will report to the EC at each monthly EC meeting to inform them of the progress of the group, and the full EC will have the final say on when the JSR is ready to progress through each phase.

2.13 Please describe how the RI and TCK will de 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.

This JSR will not produce an RI or TCK. See Appendix B of the JCP 2.5 document.

2.14 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.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

This JSR will not produce an RI or TCK. See Appendix B of the JCP 2.5 document.

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.

JCP 2.5 document: http://jcp.org/en/procedures/jcp2
The Spec Lead Guide http://www.jcp.org/en/resources/guide
The JSR Submission Form http://www.jcp.org/en/jsr/proposal

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

JCP 2.5 defines the starting point for this JSR.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

This JSR will not produce an RI or TCK. See Appendix B of the JCP 2.5 document.