Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 348: Towards a new version of the Java Community Process

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle Corporation

Name of Contact Person: Patrick Curran

E-Mail Address: patrick.curran@oracle.com

Telephone Number: +1 650 506 3875

Fax Number: +1 650 506 3875


Specification Lead: Patrick Curran

E-Mail Address: patrick.curran@oracle.com

Telephone Number: +1 650 506 3875

Fax Number: +1 650 506 3875


Initial Expert Group Membership:

The initial Expert Group membership consists of all members of the ME and the SE/EE Executive Committees. At the time of writing these are:

Stefano Andreani, Aplix, AT&T, CableLabs, Credit Suisse, Eclipse Foundation, Ericsson, Fujitsu, Goldman Sachs, Google, Hewlett-Packard, IBM, Intel, Werner Keil, London Java Community, Nokia, Oracle, Red Hat, Research In Motion, Samsung, SAP, Sean Sheedy, Siemens, SK Telecom, SouJava, T-Mobile, Alex Terrazas, TOTVS, Vodafone, VMware.

Supporting this JSR:

The following members of the ME and the SE/EE Executive Committees support this JSR:

Stefano Andreani, Aplix, AT&T, CableLabs, Credit Suisse, Eclipse Foundation, Ericsson, Fujitsu, Goldman Sachs, Hewlett-Packard, IBM, Intel, Werner Keil, London Java Community, Nokia, Oracle, Red Hat, Research In Motion, Samsung, SAP, Sean Sheedy, Siemens, SK Telecom, SouJava, T-Mobile, Alex Terrazas, TOTVS, Vodafone, VMware.



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR proposes changes to the JCP Process Document in the following areas:

In addition, the Executive Committee Members' Guide, which currently has an "unofficial" status, will be formalized and published as the EC Standing Rules, and both documents will be cleaned up and clarified where necessary.

This JSR (JCP.next JSR1) is intended to be delivered within approximately six months. The Expert Group will therefore focus on items that have broad consensus and that are relatively simple to implement. More complex changes - including any that require modifications to the JSPA - will be deferred to a follow-on JSR (JCP.next JSR2) which will be filed shortly after this JSR.

During the execution of the JSR the Spec Lead and Expert Group may decide to add additional items. In the interests of completing this JSR within the target time-frame it is also possible that some items will be deferred to the follow-on JSR.

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

When completed the resulting JCP Process Document will apply to all new JSRs commenced after the completion of this JSR and to future Maintenance Releases of existing JSRs. The Executive Committee intends to strongly encourage - though it cannot require - that they 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 Should this JSR be voted on by both Executive Committees?

Yes, as required by the JCP's rules.

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

The specific examples discussed below are intended to provide examples of the kind of changes the Expert Group will consider. They should therefore be interpreted as goals rather than commitments.

2.5.1 Transparency

Expert Group transparency

This JSR will further increase transparency of Expert Group (EG) operations by mandating certain practices that are currently merely recommended (for example requiring all Expert Group business to be carried out on public mailing lists, requiring issues and comments to be tracked through a publicly viewable issue-tracking mechanism, and requiring EGs to respond publicly to all comments.)

Executive Committee transparency

The JSR will increase transparency of Executive Committee (EC) operations by formalizing procedures that are currently undocumented (for example, the legal review of proposed licensing terms,) or where the documentation is not available publicly (for example, the non-normative and private EC Members' Guide will be incorporated into a public normative EC Standing Rules document.)

Election transparency

The Expert Group will explore ways to make the annual election process more transparent, by encouraging Executive Committee and JCP membership participation in the nomination process, and by ensuring that the voting membership has the greatest possible opportunity to "meet the candidates."

License transparency

The existing process reqiures that Spec Leads disclose Specification, RI, and TCK terms in advance. This requirement will be revised to ensure that changes to these terms can be tracked over time. (The Change Log produced during Maintenance Reviews, which currently specifies only changes to the Specification, will be expanded to include changes to the license terms - and also changes to the RI and TCK where applicable.) Additionally, the language will be revised to make it clear that licenses originally offered may not later be withdrawn (though additional licenses may be also offered.)

TCK transparency

Currently the results of the TCK testing process are often not disclosed to the public. The EG will explore ways to increase transparency in this area, for example by publishing lists of compatible implementations on jcp.org and by removing any barriers to the disclosure of test results by licensees to their customers.

IP flow transparency

Because many Expert Groups already carry out their work in a transparent manner, and because all EGs will be required to do so in the future, it is important that any legal Terms of Use associated with collaboration software that EGs use in the course of their work be verified as compatible with the JSPA. This JSR will require the disclosure and legal review of such Terms of Use.

2.5.2 Participation

The JSR will make a variety of changes to ensure broad participation in the activities of the Executive Committees and Expert Groups. The EG will explore way to enable the membership of the organization to participate in the activities of the ECs through public teleconferences, meetings, email aliases, and discussion forums. The process of recruiting Expert Group members will be made more public to ensure that all applications are fairly considered. In order to ensure that Spec Leads and EG members perform their duties responsibly, the processes for replacing those who do not will be improved. Similarly, Executive Committee members will be encouraged to attend meetings and to vote on JSRs by the application of penalties on those who fail in their duties.

2.5.3 Agility

The JSR will propose changes to improve the speed with which JSRs can be moved through the process, primarily by the imposition of time-outs for inactive or slow-moving JSRs. (The procedures discussed in the Participation section above will also help in this area.)

The Maintenance process will be improved by aligning it more closely with the Final Release process and by changes to ensure that updated Specifications, RIs, and TCKs are published promptly.

2.5.4 Governance

Recognizing that Java is a single platform, the Expert Group will explore changes that would facilitate merging the two Executive Committees into one in the follow-on JSR (JCP.next JSR2.)

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

See above.

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

Not applicable.

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

Not applicable.

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

Not applicable.

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

Not applicable.

2.11 Are there any internationalization or localization issues?

Not applicable.

2.12 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 a new version of the JCP Process document and the Executive Committee Members' Guide, therefore replacing the current versions of these documents.

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

JSR submittal: May 2011
Early Draft Review: July 2011
Public Draft Review: August 2011
Proposed Final Draft: September 2011
Final Approval Ballot: October 2011

This is a deliberately aggressive schedule which may need to be amended as the JSR progresses. However, the Spec Lead intends to defer lengthy or difficult items to a follow-on JSR in order to enable this JSR to be completed rapidly. The estimated date for the completion of the follow-on JSR is May 2012.

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

The two ECs will together form the Expert Group for this JSR. The Chair of the organization 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 on a weekly or bi-weekly basis. 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 Wikis.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The joint ECs will form the Expert Group for this JSR and will have therefore full insight in the progress of this JSR. All discussions will be carried out or reported on a public mailing list, and all materials generated by the EG will be published. The community will be encouraged to provide feedback through a public alias, and formal comments will be logged and publicly responded to. See this JSR's java.net project for details.

2.16 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.

Not applicable.

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

Not applicable.





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.