 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 244: JavaTM Platform, Enterprise Edition 5 (Java EE 5) Specification
Updates to the Original Java Specification Request (JSR) The following updates have been made to the original request.
2006.02.22:
2.1 Please describe the proposed Specification:This JSR is to develop Java EE 5, the next release of the JavaTM Platform, Enterprise Edition, targeted to ship in the second quarter of 2006.
The major theme for the next version of Java EE is ease of development. The clear message we've heard from Java EE vendors and users is that the Java EE platform must evolve quickly to support a wider range of developers, including less sophisticated developers. JSR-175 (A Metadata Facility for the JavaTM
Programming Language) is the enabling facility for a new declarative style of programming that significantly simplifies many programming tasks. Java EE must move quickly to take advantage of this capability and deliver significant improvements to ease of development for Java EE developers. In particular, this capability will be used to simplify the development of web service applications. J2EE 1.4 delivered basic web services support, including support for the WS-I Basic Profile, for the Java platform. Web service standards continue to evolve and it is critical that the Java platform support the latest web service standards. We propose that:
Java EE 5 may also provide minor enhancements to existing APIs and small additional APIs, provided they meet the time and resource constraints of this release. This JSR will not itself define any new APIs, rather it will enumerate APIs defined in other JSRs or through the JCP maintenance process. We propose to include the following new APIs or API revisions in Java EE 5 in support of the above goals:
In addition, to smooth the integration of JSF with JSP, a revision of the JSP specification will be required to integrate the two technologies and to resolve differences in their expression
languages. A JSR will be filed shortly to cover this work. We believe that it is critical to deliver a Java EE platform with enhanced ease of development as soon as possible. To be successful, the target feature set will need to be carefully managed. Very few technologies that aren't already well defined will be able to be included, and such new technologies will need to be tightly focused on the essential items necessary for enhanced ease of development support. Nearly all of the JSRs listed above are well underway. Spec leads for all included JSRs will need to remain focused on the goal of delivering enhanced ease of development support in Java EE
5 as soon as possible. Those that complete in time will be included in Java EE 5. Those that fail to complete in time may not be included. 2.13 Please describe the anticipated schedule for the development of this specification.We hope to deliver the final specification, reference implementation, and TCK in the first quarter of 2006. This implies that the specification must reach Proposed Final Draft in the third quarter of 2005. A rough schedule would be:
At JavaOne 2005, Sun announced new naming for the Java platform. "J2EE 5.0" will now be known as "Java EE 5". Names of previous releases are not changed.
18 July 2005:
2.1 Please describe the proposed Specification:This JSR is to develop Java EE 5, the next release of the JavaTM Platform, Enterprise Edition, targeted to ship in the first quarter of 2006. NOTE that this information has been updated since this update. The major theme for the next version of Java EE is ease of development. The clear message we've heard from Java EE vendors and users is that the Java EE platform must evolve quickly to support a wider range of developers, including less sophisticated developers. JSR-175 (A Metadata Facility for the JavaTM
Programming Language) is the enabling facility for a new declarative style of programming that significantly simplifies many programming tasks. Java EE must move quickly to take advantage of this capability and deliver significant improvements to ease of development for Java EE developers. In particular, this capability will be used to simplify the development of web service applications. J2EE 1.4 delivered basic web services support, including support for the WS-I Basic Profile, for the Java platform. Web service standards continue to evolve and it is critical that the Java platform support the latest web service standards. We propose that:
Java EE 5 may also provide minor enhancements to existing APIs and small additional APIs, provided they meet the time and resource constraints of this release. This JSR will not itself define any new APIs, rather it will enumerate APIs defined in other JSRs or through the JCP maintenance process. We propose to include the following new APIs or API revisions in Java EE 5 in support of the above goals:
In addition, to smooth the integration of JSF with JSP, a revision of the JSP specification will be required to integrate the two technologies and to resolve differences in their expression
languages. A JSR will be filed shortly to cover this work. We believe that it is critical to deliver a Java EE platform with enhanced ease of development as soon as possible. To be successful, the target feature set will need to be carefully managed. Very few technologies that aren't already well defined will be able to be included, and such new technologies will need to be tightly focused on the essential items necessary for enhanced ease of development support. Nearly all of the JSRs listed above are well underway. Spec leads for all included JSRs will need to remain focused on the goal of delivering enhanced ease of development support in Java EE
5 as soon as possible. Those that complete in time will be included in Java EE 5. Those that fail to complete in time may not be included. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This specification defines the next release of the Java EE Platform. 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 specification defines the next release of the Java EE Platform. It will be based on the corresponding release of the Java SE platform. 2.5 What need of the Java community will be addressed by the proposed specification?Java EE 5 will extend J2EE 1.4 and build on J2SE 5.0, taking particular advantage of JSR-175 to make development of applications on the Java EE platform significantly easier, thus making Java EE attractive to a broader range of developers. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The Java EE Platform itself does not require a package name. All of its requirements are reflected in the packages of its constituent Java APIs. 2.10 Are there any security issues that cannot be addressed by the current security model?Java EE 5 addresses mechanisms and policies required for secure usage of its constituent component models and access APIs. These mechanisms must be compatible with the security facilities of J2SE 5.0. 2.11 Are there any internationalization or localization issues?The Java EE technologies face cross-platform internationalization issues such as locale and character encoding identification and support for the latest Unicode version, as well as technology-specific internationalization issues. The component JSRs need to address these issues, leveraging the internationalization functionality provided by the Java SE platform where possible. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?Other than the Java EE specification itself and the new versions of its constituent component models and access APIs, Java EE 5 should not require other existing specifications to be revised. 2.13 Please describe the anticipated schedule for the development of this specification.We hope to deliver the final specification, reference implementation, and TCK in the first quarter of 2006. This implies that the specification must reach Proposed Final Draft in the third quarter of 2005. A rough schedule would be:
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the following is a summary of Sun's anticipated principal license terms and conditions for the Java Platform Enterprise Edition, version 5. Non-Commercial Use The Java EE 5 Compatibility Test Suite (CTS) will be licensed at no charge, without support, to qualified not-for-profit entities in accordance with the terms of Compatibility Testing Scholarship Program. For more information, please refer to: http://java.sun.com/scholarship/. The required brand license is available free of charge for non-commercial use. Reference Implementation (RI) source will be available under Sun Community Source License (SCSL) version 2.8. The RI source will also be available under Java Research License to encourage academic development. Licensing of the RI is not required for the licensing of the CTS. Commercial Use Covers all use that doesn't fall under Non-Commercial Use" above. Compatibility Fee There are two Compatibility licenses available for commercial users, which include CTS and brand licensing. Option 1: The CTS will be licensed without the RI, for a flat fee of $350K per year per Marketed Product*. To promote broader distribution of the Java EE technology, companies may elect to pay a Compatibility fee of 2% of Adjusted Revenues* per year, subject to an annual cap of $700K per year per Marketed Product. Option 2: The CTS and RI with redistribution rights will be licensed for a flat fee of $500K per year per Marketed Product. To promote broader distribution of the Java EE technology, companies may elect to pay a Compatibility fee of 3% of Adjusted Revenues per year, subject to an annual cap of $1,000K per year per Marketed Product. Support CTS Support is required for commercial use, and is sold in increments of 10 hours/week of compatibility testing support for $135K fee. The CTS Support includes updates and upgrades to the CTS and RI at no additional charge. Reference Implementation Source support is available in 20 hours/week increments for $200K fee. Definitions For purposes of these terms: Marketed Product is intended to describe a licensee's product that has its own differentiation and marketing collateral. It may comprise one price list entry, or in some cases multiple entries (for example. to account for different localizations or delivery packaging). By way of example, in terms of Sun's product line we wouldn't consider Sun's Java Application Server to be a Marketed Product, but Sun's Java Application Server Platform Edition, Standard Edition, and Enterprise Edition are 3 Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed Product. Adjusted Revenues is intended to include all gross corporate revenue related to Marketed Products, and includes without limitation both licensing and services. 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.Java 2 Platform, Enterprise Edition Specification Version 1.4,
and related specifications
Java 2 Platform, Standard Edition, v5.0 API Specification
Web Services Metadata for the Java Platform JSR-220 EJB 3.0 JSR-222 Java APIs for XML Data Binding
2.0 JSR-224 Java APIs for XML-based Web Services
2.0 JSR-127 JavaServer Faces 3.2 Explanation of how these items might be used as a starting point for the work.These specifications will be the basis for Java EE 5. ****************At JavaOne 2004, Sun announced that it was changing the version numbers of the J2SE and J2EE platforms to reflect the real maturity of those platforms. Therefore all references to "J2EE 1.5" have been changed to "J2EE 5.0" throughout the request. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Bill Shannon E-Mail Address: bill.shannon@sun.com Telephone Number: +1 408 276 7280 Fax Number: + 1 408 276 7191 Specification Lead: Bill Shannon E-Mail Address: bill.shannon@sun.com Telephone Number: +1 408 276 7280 Fax Number: + 1 408 276 7191 Initial Expert Group Membership: BEA Supporting this JSR: BEA Section 2: Request
2.1 Please describe the proposed Specification:This JSR is to develop J2EE 5.0, the next release of the JavaTM 2 Platform, Enterprise Edition, targeted to ship in the second half of 2005. The major theme for the next version of J2EE is ease of development.
The clear message we've heard from J2EE vendors and users is
that the J2EE platform must evolve quickly to support a wider
range of developers, including less sophisticated developers.
JSR-175 (A Metadata Facility for the JavaTM
Programming
Language) is the enabling facility for a new declarative style of
programming that significantly simplifies many programming tasks.
J2EE must move quickly to take advantage of this capability and deliver
significant improvements to ease of development for J2EE developers. In
particular, this capability will be used to simplify the development of
web service applications. J2EE 1.4 delivered basic web services support, including support for
the WS-I Basic Profile, for the Java platform. Web service
standards continue to evolve and it is critical that the Java platform
support the latest web service standards. We propose that:
J2EE 5.0 may also provide minor enhancements to existing APIs and small additional APIs, provided they meet the time and resource constraints of this release. This JSR will not itself define any new APIs, rather it will enumerate APIs defined in other JSRs or through the JCP maintenance process. We propose to include the following new APIs or API revisions in J2EE 5.0 in support of the above goals:
In addition, to smooth the integration of JSF with JSP, a revision
of the JSP specification will be required to integrate the two
technologies and to resolve differences in their expression
languages. A JSR will be filed shortly to cover this work. We believe that it is critical to deliver a J2EE platform with enhanced ease of development as soon as possible. To be successful, the target feature set will need to be carefully managed. Very few technologies that aren't already well defined will be able to be included, and such new technologies will need to be tightly focused on the essential items necessary for enhanced ease of development support. Nearly all of the JSRs listed above are well underway. Spec leads
for all
included JSRs will need to remain focused
on the goal of delivering enhanced ease of development support in J2EE
5.0 as soon as
possible. Those that complete in time will be included in J2EE 5.0.
Those that fail to complete in time may not be included. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This specification defines the next release of the J2EE Platform. NOTE: this information has been updated from this original request.
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 specification defines the next release of the J2EE Platform. It will be based on the corresponding release of the J2SE platform. NOTE: this information has been updated from this original request.
2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?J2EE 5.0 will extend J2EE 1.4 and build on J2SE 5.0, taking particular advantage of JSR-175 to make development of applications on the J2EE platform significantly easier, thus making J2EE attractive to a broader range of developers. NOTE: this information has been updated from this original request.
2.6 Why isn't this need met by existing specifications?While existing (in progress) specifications provide the base capabilities, no other specification can unite these components into a coherent Java platform. 2.7 Please give a short description of the underlying technology or technologies:A detailed description of J2EE 1.4 functionality can be found in the J2EE 1.4 Specification http://java.sun.com/j2ee/download.html#platformspec. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The J2EE Platform itself does not require a package name. All of its requirements are reflected in the packages of its constituent Java APIs. NOTE: this information has been updated from this original request.
2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?J2EE 5.0 addresses mechanisms and policies required for secure usage of its constituent component models and access APIs. These mechanisms must be compatible with the security facilities of J2SE 5.0. NOTE: this information has been updated from this original request.
2.11 Are there any internationalization or localization issues?The J2EE technologies face cross-platform internationalization issues such as locale and character encoding identification and support for the latest Unicode version, as well as technology-specific internationalization issues. The component JSRs need to address these issues, leveraging the internationalization functionality provided by the J2SE platform where possible. NOTE: this information has been updated from this original request.
2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?Other than the J2EE specification itself and the new versions of its constituent component models and access APIs, J2EE 5.0 should not require other existing specifications to be revised. NOTE: this information has been updated from this original request.
2.13 Please describe the anticipated schedule for the development of this specification.We hope to deliver the final
specification, reference
implementation,
and TCK in the second half of 2005.
This implies that the specification
must reach Proposed Final Draft early
in the first half of 2005. A rough schedule would be:
2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. 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.Transparency plan: a) The specification lead will maintain an interest list for JCP members outside of the Expert Group. The specification lead will publish periodic milestone drafts and status to this list. The Expert Group may also use the list to request feedback on key issues facing the group. b) The specification lead will on a quarterly basis provide a brief JSR status to the JCP PMO, for publication to the Java community. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter. 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.The RI and TCK will be delivered in the same way they were delivered for J2EE 1.4. 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).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the following is a summary of Sun's anticipated principal license terms and conditions for the Java 2 Platform Enterprise Edition, version 5.0. Non-Commercial Use The J2EE 5.0 Compatibility Test Suite (CTS) will be licensed at no charge, without support, to qualified not-for-profit entities in accordance with the terms of Compatibility Testing Scholarship Program. For more information, please refer to: http://java.sun.com/scholarship/. The required brand license is available free of charge for non-commercial use. Reference Implementation (RI) source will be available under Sun Community Source License (SCSL) version 2.8. The RI source will also be available under Java Research License to encourage academic development. Licensing of the RI is not required for the licensing of the CTS. Commercial Use Covers all use that doesn't fall under "Non-Commercial Use" above. Compatibility Fee There are two Compatibility licenses available for commercial users, which include CTS and brand licensing. Option 1: The CTS will be licensed without the RI, for a flat fee of $350K per year per Marketed Product*. To promote broader distribution of the J2EE technology, companies may elect to pay a Compatibility fee of 2% of Adjusted Revenues* per year, subject to an annual cap of $700K per year per Marketed Product. Option 2: The CTS and RI with redistribution rights will be licensed for a flat fee of $500K per year per Marketed Product. To promote broader distribution of the J2EE technology, companies may elect to pay a Compatibility fee of 3% of Adjusted Revenues per year, subject to an annual cap of $1,000K per year per Marketed Product. Support CTS Support is required for commercial use, and is sold in increments of 10 hours/week of compatibility testing support for $135K fee. The CTS Support includes updates and upgrades to the CTS and RI at no additional charge. Reference Implementation Source support is available in 20 hours/week increments for $200K fee. Definitions For purposes of these terms: Marketed Product is intended to describe a licensee's product that has its own differentiation and marketing collateral. It may comprise one price list entry, or in some cases multiple entries (for example. to account for different localizations or delivery packaging). By way of example, in terms of Sun's product line we wouldn't consider Sun's Java Application Server to be a Marketed Product, but Sun's Java Application Server Platform Edition, Standard Edition, and Enterprise Edition are 3 Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed Product. Adjusted Revenues is intended to include all gross corporate revenue related to Marketed Products, and includes without limitation both licensing and services. NOTE: this information has been updated from this original request.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.Java 2 Platform, Enterprise Edition Specification Version 1.4,
and related specifications
Java 2 Platform, Standard Edition, v5.0 API Specification
Web Services Metadata for the Java Platform JSR-220 EJB 3.0 JSR-222 Java APIs for XML Data Binding
2.0 JSR-224 Java APIs for XML based RPC
2.0 JSR-127 JavaServer Faces
3.2 Explanation of how these items might be used as a starting point for the work.These specifications will be the basis for J2EE 5.0. NOTE: this information has been updated from this original request.
|
