• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Patrick Curran	Oracle
Expert Group
	Apache Software Foundation	BEA Systems	Borland Software Corporation
	Ericsson AB	Fujitsu Limited	Google Inc.
	Hewlett-Packard	IBM	Intel Corp.
	Lea, Doug	Motorola	Nokia Corporation
	Nortel	NTT DoCoMo, Inc.	Oracle
	Orange France SA	Philips Electronics UK Ltd	Qisda Corporation
	Red Hat	Research In Motion, LTD (RIM)	Samsung Electronics Corporation
	SAP SE	SAS Institute Inc.	Siemens AG
	Sony Ericsson Mobile Communications AB	Suleiman, Hani	Sun Microsystems, Inc.
	Vodafone Group Services Limited

This JSR has been Withdrawn
Reason: This JSR was withdrawn because it is obsolete. It was replaced by two new JSRs that will develop short-term and longer-term changes to the Process Document and the JSPA. Work from JSR 306 was to be incorporated into the new JSRs as appropriate. Patrick Curran was to be the Spec Lead for these JSRs, while the Expert Group will be the current membership of both the JCP Executive Committees.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc

Name of Contact Person: Onno Kluyt

E-Mail Address: onno.kluyt@sun.com

Telephone Number: +1 650 352 4752

Fax Number: +1 650 352 4752

Specification Lead: Onno Kluyt

E-Mail Address: onno.kluyt@sun.com

Telephone Number: +1 650 352 4752

Fax Number: +1 650 352 4752

Initial Expert Group Membership:

Apache, BEA, Borland, Ericsson, Fujitsu, Google, Hewlett-Packard, IBM, Intel, Red Hat Middleware, Doug Lea, Matsushita, Motorola, Nokia, Nortel Networks, NTT Docomo, Oracle, Orange France, Philips, Research In Motion, Samsung, SAP, SAS Institute, Siemens, SonyEricsson, Hani Suleinman, Sun, Symbian, Vodafone

Supporting this JSR:

Apache, BEA, Borland, Ericsson, Fujitsu, Google, Hewlett-Packard, IBM, Intel, Red Hat Middleware, Doug Lea, Matsushita, Motorola, Nokia, Nortel Networks, NTT Docomo, Oracle, Orange France, Philips, Research In Motion, Samsung, SAP, SAS Institute, Siemens, SonyEricsson, Hani Suleinman, Sun, Symbian, Vodafone

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR proposes several changes to the JSPA and to the JCP process document. The changes are both of a streamlining nature:

* further improve the transparency of the process;
* further optimize the average duration of JSRs;
* how can individuals best participate in the process;

as well as of a potentially more fundamental nature:

* allowing non-Java implementations of a JSR's specification;
* ability to create liaison relationships with other standards organizations;
* easing the migration of pre--existing technology towards an agreed upon standard;
* the availability of TCK and associated licensing information upon completion of a JSR.

During the execution of the JSR the Spec Lead and Expert Group may decide to add additional items and may also decide to drop items if it is deemed that a reasonable consensus cannot be reached or in order to complete the work of this JSR in a reasonable time frame.

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

When completed the resulting JCP Process Document and JSPA will apply to all new JSRs commenced after the completion of this JSR.

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. Per the rules of the JCP, Process Change JSRs are voted upon by both ECs.

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

Allowing non-Java implementations of a JSR's specification:
There are standardization efforts in the JCP and in other standard creation environments which are focused on creating technologies that facilitate interoperation between different platforms and systems. This includes, for example, technologies related to SOA and web services. Among several JCP members there is a business need to be able to apply these standardization efforts as they take place in the JCP in a Java context but also in non-Java contexts. The latter is currently not possible within the JCP.

Ability to create liaison relationships with other standards organizations:
The work of several JSRs either depends on the work of other standards organizations, or the work of other standards organizations depends on the work of these JSRs. Both Spec Leads and representatives of these other standards organizations desire to be able to exchange working drafts, discuss ideas etc. This item will investigate which changes to the JSPA need to be made to allow such interactions.

Easing the migration of pre--existing technology towards an agreed upon standard:
As the use and appeal of the Java technology continues to expand from the language itself and core platform facilities, increasingly JCP members are motivated to bring existing technologies (either from products or created through other, collaborative, projects) into the JCP as foundations for new standardization efforts. The current JCP structure is experienced as too rigid with regards to allowing the members to manage the life cycle of the existing technology in the light of the progressing JSR and to migrate products and their customers over time to the new standard.

The availability of TCK and associated licensing information upon completion of a JSR:
What information should the Spec Lead be required to provide in order to make it known to interested parties how and where to obtain the TCK, what licensing and other requirements need to be met in order to obtain a TCK?

How can individuals best participate in the process?
This JSR plans to explore how individual members can most effectively participate both to their satisfaction as well as to the benefit of the Java Community.

Further improve the transparency of the process:
Since the introduction of JCP 2.5 in October 2002 which regulated the right to build independent implementations, the Java community at large has grown accustomed not only to open source software methodologies and business models but on average expects that specification development happens in a similar spirit. The JSR plans to explore what steps can be taken, both mandatory through the process document, as well as voluntary or desired behavior through the Spec Lead Guide and facilities provided by the JCP.org web site.

Further optimize the average duration of JSRs:
Should there be maximum time frames for JSRs to progress from one stage to a next? What consequences should there be if a JSR does not adhere to such a time frame? Are there optimizations that can be made to the current rules that will enable Spec Leads and Expert Groups to successfully complete their work more speedily?
What should be the status of an expert group upon completion of the JSR? The process document states that the expert group "disbands" however in practice most spec leads continue to interact with the expert group after the JSR is final.

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 JSPA, therefore replacing the current versions of these documents.

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

JSR submittal: Late September / Early October 2006
Early Draft Review: December 2006
Public Draft Review: February 2007
Proposed Final Draft: April 2007
Final Approval Ballot: May 2007

The submitter recognizes that this is an aggressive schedule. During the course of the JSR the schedule will be amended as necessary. The Expert Group and Spec Lead may decide to defer items to further revisions if the resolution of such items would significantly prolong the duration of this JSR at the detriment of the community's ability to benefit from the already resolved items.

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. A member of the PMO will fulfill the role of Spec Lead. It is anticipated that (portions of) the EC meetings will be used for Expert Group deliberations. In addition, the Spec Lead will schedule regular teleconference meetings for the weeks in between the EC meetings. If it so desires the ECs may form from its representatives one or more so-called ad-hoc groups to perform the detailed work on one or more items that this JSR proposes to change. These ad-hoc groups will report back to the full Expert Group during EC meetings. It is also expected that email will be used to discuss and work out the change items. The Expert Group and Spec Lead may elect to use the EC Member Guide as its decision making model.

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. The Spec Lead also plans to provide any appropriate progress information, or draft working documents, as appropriate to the Community Update page for this JSR. The Spec Lead will actively pursue community and public feedback on the official drafts of this JSRs during Early Draft Review, Public Draft Review and other mandatory milestones for a JSR. It is also thought possible that the Spec Lead may interview current Spec Leads, other JCP members and developers on topics related to the work of this JSR and present this material to the Expert Group.

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.

• The JCP 2.6 Process document
  
• The JSPA
  
• The Spec Lead guide
  
• The OASIS IP policy
  

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

The JCP documents describe the current structure and operation of the JCP and form the basis for evolving the rules of the community. The OASIS IP policy has been offered as input for the discussion on allowing non-Java implementations of JSRs.

Section 4: Additional Information (Optional)

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