The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 243

Find JSRs

• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs
My JCP
Register for Site
Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JCP Info
• 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

Status: Maintenance
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.

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original proposal:

2018年02月13日:
Following the successful transfer ballot, the Maintenance Lead role has moved from Oracle to Craig Russell, an individual.

2004年06月22日:

Initial Expert Group Membership:

Xcalia
POET Software
David Ezzio
David Jordan
Tech@Spree
Robin Roos
SAP
SolarMetric
Oliver Kamps
JBOSS

Supporting this JSR:

Sun Microsystems, Inc.
Poet Software
Progress Software
SolarMetric
Orientechnologies
Xcalia
SAP
Versant
Oliver Kamps
Robin Roos
JBoss Group
Tech@Spree

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
POET Software
David Ezzio
Oracle Corporation
David Jordan
Tech@Spree
Robin Roos
SAP
SolarMetric
Oliver Kamps
JBOSS

Supporting this JSR:

NOTE: This information has been updated from the information below.

Sun Microsystems, Inc.
Poet Software
Progress Software
SolarMetric
Orientechnologies
LIBeLIS
SAP
Oracle
Versant
Oliver Kamps
Robin Roos
JBoss Group
Tech@Spree

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.
This technology has been used to develop implementations for file storage and relational and object databases. Over a dozen commercial implementations have been developed to date. Additionally, the technology has been exploited to develop EJB Container Managed Persistence (CMP) for application servers.
Features to be added to the JDO specification include:
Relational Database Mapping:
The programmer's view of the datastore hides the details of the underlying datastore, which is attractive but leads to some issues. Different JDO vendors have implemented mappings to relational databases differently, and the mappings are not portable among vendors. This JSR will address a common mapping format to allow a higher degree of portability of applications.
Disconnected operation:
A primary use-case for JDO is in a middle tier of a multi-tier architecture. Rich clients (http clients running applets, web services clients, and ORB clients) may wish to extract a subset of values from the database in a structured (domain model) format, and update this information. Once updated, the information is sent back to a middle tier, where the changes are applied to the datastore. This JSR will address the APIs in the middle tier to facilitate this use-case.
Broaden the range of implementations:
Certain JDO 1.0 specification restrictions reduce the acceptance of the API by potential JDO vendors. Limitations include a requirement for binary compatibility to the Reference Enhancement contract and a requirement that only classes, not interfaces, can be persistent. This JSR will address these limitations. Alignment with J2EE:
While the JDO technology is suitable as a component in the J2EE architecture, certain services are required from the server that are not currently standardized. Part of this JSR will recommend standard APIs to provide these services. Part of this alignment will specify the portable behavior of transaction completion in the web and ejb containers.
Extensions to JDO queries:
JDOQL provides a standard way to access persistent instances based on values and relationships, but is limited in what can be returned as the result. This JSR will extend the range of return values to include projected fields, collections of instances identified in navigational expressions, and aggregate data such as MIN, MAX, SUM, AVG, and COUNT. Additional methods will be defined to perform string manipulations in filters.
Relationships:
The JDO object model does not specify bidirectional or composition relationships among object classes. This JSR will consider issues regarding managed bidirectional relationships and composition relationships including cascade delete semantics.
Maximize JDO backward compatibility:
Many applications and deployments have significant investments in the JDO technology. Any improvements to the API will attempt to maintain backward compatibility to all previous JDO specifications.
Minor usability features:
A number of usability features will be considered, based on feedback from user discussions on sites such as TheServerSide and JDOCentral.

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:
JSR-012 Java Data Objects (JDO)
JSR-014 Java Generics will be used as an alternative to certain JDO metadata
JSR 175 Metadata Facility will be used as an alternative to certain JDO metadata
Other specifications: not applicable.

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.
The Metadata Facility could be used as defaults for the JDO metadata required by the proposed specification.
Generics can be used to obviate the need for certain JDO metadata, especially the types of elements, keys, and values for relationships, collections, and maps.