Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
|
JSRs: Java Specification Requests
JSR 243: JavaTM Data Objects 2.0 - An Extension to the JDO specification
JCP version in use: 2.11 Java Specification Participation Agreement version in use: 2.0 Description: The high level objectives are to make JDO easier to use, closely align JDO with J2EE, standardize JDO's database support, and broaden the scope of JDO. Team
Updates to the Original Java Specification Request (JSR) The following information has been updated from the original proposal:
2018.02.13: 2004.06.22: Initial Expert Group Membership: Xcalia Supporting this JSR: Sun Microsystems, Inc. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Craig Russell E-Mail Address: Craig.RussellNo@Spamsun.com Telephone Number: +1 408 276 5638 Fax Number: +1 408 276 7191 Specification Lead: Craig Russell E-Mail Address: Craig.RussellNo@Spamsun.com Telephone Number: +1 408 276 5638 Fax Number: +1 408 276 7191 Initial Expert Group Membership: NOTE: This information has been updated from the information below. LIBeLIS Supporting this JSR: NOTE: This information has been updated from the information below. Sun Microsystems, Inc. Section 2: Request
2.1 Please describe the proposed Specification:The JDO API was released in spring of 2002 and had one maintenance release late in 2003. The initial release provided a database abstraction that permitted API access to datastores without detailed knowledge of the underlying datastore API. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target platforms are desktop and server. 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.Java Data Objects was designed for use in J2SE and J2EE. Two tier applications written for J2SE can use JDO directly. Application components such as servlets, JavaServer Pages, message-driven beans, and session beans can use JDO as a managed component. A subset of functionality would be appropriate for J2ME but this will require a separate JSR. 2.4 Should this JSR be voted on by both Executive Committees?No, it is being submitted for J2SE and J2EE platforms. 2.5 What need of the Java community will be addressed by the proposed specification?The Java community will benefit from the additional API and usability improvements that will ease portability of relational data access from JDO applications. 2.6 Why isn't this need met by existing specifications?Please see 2.1 above. 2.7 Please give a short description of the underlying technology or technologies:Please see 2.1 above. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The specification will continue to use the existing javax.jdo package. 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?No 2.11 Are there any internationalization or localization issues?No. The reference implementation will be internationalized, but not localized. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?JDO 1.0.1 as described by JSR 12 will be superseded by JDO 2.0. 2.13 Please describe the anticipated schedule for the development of this specification.We expect to deliver a community review draft by mid 2004 and the final release early to mid 2005. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The Expert Group will use email and the private JSR homepage provided as part of the Java Community Process. Face-to-face meetings will be held 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 specification lead will maintain an interest alias 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. 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.Both the RI and TCK will be delivered as stand-alone packages. The objective for this JSR is to support Java(TM) 2 Platform, Standard Edition (J2SE) 1.3 for runtime, while potentially taking advantage of new features of J2SE 1.5 when it is the compiler and JRE used for persistence-capable classes and interfaces. The Java Data Objects library interface definitions and implementation will be built using J2SE 1.3. The Reference Implementation and Technology Compatibility Kit will be built using J2SE 1.3. Implementations that support only J2SE 1.3 will only be required to pass the basic TCK. Implementations that support J2SE 1.5 will be required to pass the extended TCK tests as well. Compatibility with J2EE 1.3 is an objective, with support for future versions as well. 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 Sun standard license terms for Java technology (SCSL) will apply to the Specification and RI; the TCK will be licensed according to Sun's standard TCK license terms. 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.JSRs: 3.2 Explanation of how these items might be used as a starting point for the work.JDO 1.0.1 is the starting point for this JSR. |