 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 250: Common Annotations for the JavaTM Platform
The following changes were made to the original proposal:
2016.05.31: 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 Supporting this JSR: BEA 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 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
Java 2 Platform, Standard Edition, v5.0 API Specification
Web Services Metadata for the JavaTM Platform
JSR-220 EJB 3.0
JSR-221 JDBC 4.0
JSR-222 Java APIs for XML Data Binding 2.0
JSR-224 Java APIs for XML based RPC 2.0
JSR-244 Java 2 Platform, Enterprise Edition Specification Version 1.5 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)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR. |
