Description
Stage timeline
| Stage | Access | Start | Finish |
|---|---|---|---|
| Maintenance Release 3 | Download page | 02 Sep, 2016 | |
| Maintenance Review Ballot | View results | 12 Jul, 2016 | 25 Jul, 2016 |
| Maintenance Draft Review 3 | Download page | 11 Jun, 2016 | 10 Jul, 2016 |
| Maintenance Release 2 | Download page | 14 Jun, 2013 | |
| Maintenance Draft Review 2 | Download page | 21 Feb, 2013 | 25 Mar, 2013 |
| Maintenance Release | Download page | 10 Dec, 2009 | |
| Maintenance Draft Review | Download page | 22 Sep, 2009 | 22 Oct, 2009 |
| Final Release | Download page | 11 May, 2006 | |
| Final Approval Ballot | View results | 04 Apr, 2006 | 17 Apr, 2006 |
| Proposed Final Draft | Download page | 13 Oct, 2005 | |
| Public Review Ballot | View results | 19 Jul, 2005 | 25 Jul, 2005 |
| Public Review | Download page | 21 Jun, 2005 | 25 Jul, 2005 |
| Early Draft Review | Download page | 23 Mar, 2005 | 22 Apr, 2005 |
| Expert Group Formation | 31 Aug, 2004 | 20 Dec, 2004 | |
| JSR Review Ballot | View results | 17 Aug, 2004 | 30 Aug, 2004 |
Team
Specification Leads
- Rajiv MordaniOracle
Expert Group
- BEA Systems
: Seth White - Google Inc.
: Cedric Beust - IBM
: Daniel Berg - Intel Corp.
: Wayne J. Carr - Ironflare AB
: Hani Suleiman - Oracle
: Robert Clevenger - Oracle
: Rajiv Mordani - Oracle
: Harold Ogle - Oracle
: William Shannon - Pramati Technologies
: Anurag Parasar - Red Hat
: Bill Burke - Red Hat
: Gavin King - Michael Nascimento Santos
- Sun Microsystems, Inc.
: Rajiv Mordani - Sun Microsystems, Inc.
: Bill Shannon - Sybase
: Evan Ireland - TmaxSoft, Inc.
: Woo Jin Kim
Contributors
Proposal
The following changes were made to the original proposal:
2016.05.31:
The JCP version was updated to JCP 2.10; the JSR was originally completed under JCP 2.7. Additionally, Oracle added a new Maintenance Lead:
Maintenance Leads: Linda DeMichiel, Rajiv Mordani
E-Mail Addresses: linda.demichiel
Telephone Number: +1 408 276 7057, +1 408 276 7204
Fax Number: +1 408 276 7191
2010.02.15:Oracle took over as Maintenance Lead from Sun Microsystems.
Maintenance Lead: Rajiv Mordani
E-Mail Address: rajiv.mordani
Telephone Number: +1 408 276 7204
Fax Number: +1 408 276 7191
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification
Submitting Member: Sun Microsystems, Inc
Name of Contact Person: Rajiv Mordani
E-Mail Address: rajiv.mordani@sun.com
Telephone Number: +1 408 276 7204
Fax Number: +1 408 276 7191
Specification Lead: Rajiv Mordani
E-Mail Address: rajiv.mordani@sun.com
Telephone Number: +1 408 276 7204
Fax Number: +1 408 276 7191
Initial Expert Group Membership:
BEA
Oracle
Sun Microsystems Inc
Supporting this JSR:
BEA
Oracle
Sun Microsystems Inc
Section 2: Request
2.1 Please describe the proposed Specification:
This JSR well develop annotations for common semantic concepts in the J2SE and J2EE platforms that apply across a variety of individual technologies. With the addition of JSR 175 (A Metadata Facility for the JavaTM Programming Language) in the Java platform we envision that various JSRs will use annotations to enable a declarative style of programming. It would be unfortunate if these JSRs each independently defined their own annotations for common concepts. It would be especially valuable to have consistency within the J2EE 5.0 component JSRs, but it will also be valuable to allowconsistency between J2EE and J2SE. It is the intention of this JSR to define a small set of common annotations that will be available for use within other JSRs. It is hoped that this will help to avoid unnecessary redundancy or duplication between annotations defined in different JSRs. The exact set of annotations will be developed in consultation with the various specifications leads who are currently planning to use annotations within their JSRs.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
This specification is targeted for J2SE and J2EE platforms.
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 is initially targeted for J2SE and J2EE platforms.
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?
This would allow us to have the common annotations all in one place and let the technologies refer to these specification rather than have them specified in multiple specifications. This way all technologies can use the same version of the annotations and there will be consistency in the annotations used across the platforms.
2.6 Why isn't this need met by existing specifications?
Existing specifications don't use annotations currently. However once they start using it in their future versions they would need to define these annotations and so we feel we should have a place to define these common annotations in one place.
2.7 Please give a short description of the underlying technology or technologies:
The specification would depend on JSR 175(A Metadata Facility for the JavaTM Programming Language) and hence J2SE 5.0.
2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
javax.annotations
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?
This JSR would potentially define some annotations for security. However the semantics of these annotations maybe specified in the specification referring to the common annotations.
2.11 Are there any internationalization or localization issues?
This JSR will use the I18N support in J2SE.
2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
JSR 181 may need a revision.
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 early 2005. A rough schedule would be:
Aug 2004 Expert group formed
Sept 2004 First expert draft
Oct 2004 Early Draft Review
Nov 2004 Public Review
February 2005 Proposed Final Draft
March 2005 Final release.
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.
The operating plan for involvement from the community is to have the material made available early and as often as possible to the public via early access drafts and public review drafts. We may use the open development process being followed by some other JSRs using the mechanism setup at java.net. However it will be up to the expert group to decide if we want that to happen.
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 reference implementation will be made available via the J2SE and J2EE platforms as well as standalone. The TCK will be made available standalone as well as part of the CTS and JCK where 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).
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.
The Reference Implementation and associated TCK's will be made available from java.sun.com at no charge without support. J2EE and J2SE licensees will recieve support at no extra charge with an amendment to their active support agreement. Source code will be made available via the Java Distribution License (JDL).
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
http://java.sun.com/j2ee/download.html#platformspec
Java 2 Platform, Standard Edition, v5.0 API Specification
http://java.sun.com/j2se/5.0/docs/api/index.html
Web Services Metadata for the JavaTM Platform
http://jcp.org/jsr/detail/181.jsp
JSR-220 EJB 3.0
http://jcp.org/jsr/detail/220.jsp
JSR-221 JDBC 4.0
http://jcp.org/en/jsr/detail?id=221
JSR-222 Java APIs for XML Data Binding 2.0
http://jcp.org/jsr/detail/222.jsp
JSR-224 Java APIs for XML based RPC 2.0
http://jcp.org/jsr/detail/224.jsp
JSR-244 Java 2 Platform, Enterprise Edition Specification Version 1.5
http://jcp.org/en/jsr/detail?id=244
3.2 Explanation of how these items might be used as a starting point for the work.
The common concepts from these specifications would be the starting point for this JSR.
Section 4: Additional Information (Optional)