 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 12: JavaTM Data Objects (JDO) Specification
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: The JDO specification provides for interface-based definitions of data stores and transactions; and selection and transformation of persistent storage data into native JavaTM programming language objects. Please direct comments on this JSR to the Spec Lead(s) Team
Original Java Specification Request (JSR) Identification | Request | Contributions Section 1: Identification
The primary contact for this submission is: Craig Russell The contact information for the other companies who endorse this JSR is: Bernard Normier Soumitro Tagore Richard Plederedar Jack Greenfield Sriram Srinivasan Fernando Velez Henry Parnell Ron Raffensperger Lougie Anderson John Pompeii David Jordan Zaid Al-Timimi Torsten Stanienda Paul Lipton Tony Kamarainen Jeff Eastman Windward Solutions, Inc. Henry Strickland Bernd Hartings Dirk Bartels Section 2: Request
Target Java Platform:All Java platforms, including desktop, server, personal, embedded, and card, can use this API to access data. Need addressed by Java Data Objects:The Java community needs a standard way to store Java objects persistently in transactional data stores. Furthermore, it needs a standard way to treat relational database data as Java objects, and a standard way to define transactional semantics associated with those objects. The term Java Data Objects is a placeholder for this functionality, pending the choice of a final name. Existing Specifications:Existing specifications for persistence include JDBC, SQLJ, and java.util.Serializable. The JDBC and SQLJ mechanisms provide for query, transactions, and large capacity storage, but require that users learn another language (SQL). This proposal allows users to specify their application program logic, including queries, entirely in Java, and express the mapping, if any, to the database with a separate mechanism. The java.util serialization protocol provides for persistence, but it does not offer query capability, transactional behavior, nor large capacity data storage. In addition, both the serialization and SQL APIs require that the programmer explicitly fetch and store Java objects from a database; we propose transparent persistence, doing this automatically. The Java Data Objects Specification:This is a high level API that may be implemented using lower level APIs like JDBC or SQLJ PART 0 to store data. This specification provides for interface-based definition of data stores, transactions, selection, and transformation of persistent storage data into native Java objects. There are several major parts of the specification:
Package name:The working name for the package is javax.jdo. This name is subject to a better proposal during the life of the project. Platform dependencies:The Reference Implementation will be implemented in 100% Pure Java. Other implementations may use native code for parts of the underlying mapping to database storage, but native code is neither required nor proscribed. Security implications:This specification will exploit existing security mechanisms of both the Java environment and the underlying data storage mechanisms, such as relational databases or file systems. Internationalization and localization:Internationalization and localization of implementations are not required, nor are they proscribed by this specification. Risk assessment:Several vendors, independent of Sun?s activities to standardize the interface have implemented a similar specification. Thus, there is a corpus of code and techniques upon which to rely while finalizing the specification. The reference implementation can be obtained from parties interested in this specification, but there is no guarantee that negotiations for an appropriate license will be successful. The compatibility test suite is the major source of risk. An industry consortium comprising users and vendors of object databases, object relational mappings, relational databases, and Java tools may jointly develop the compatibility test suite, but there is no guarantee that the consortium will fund the work. Existing specifications:There are no existing specifications or specification requests pending that would be rendered obsolete by this specification. There are no existing specifications that would need revision as a result of this specification. Section 3: Contributions
This Specification will incorporate parts of the Object Data Management Group 3.0 persistent storage interface. A number of products from Specification participants, such as Sun's Java Blend, already conform to earlier versions of this API and participants have experience with it. The Object Data Management Group has agreed to grant all present and future rights to the interface for use by the specification lead and the community process, and the group members have volunteered to participate in the community process for work on the specification. As part of the community process, the specification will be extended to include specific requirements for storage of objects in Relational Database Management Systems and file systems, and will be aligned and integrated with evolving enterprise Java APIs such as Java Transactions and Enterprise Java Beans. Work from the OSGI (Open Services Gateway Initiative) will probably also be used in the Specification. OSGI is currently under the Java Community Process. An effort will be made to satisfy the needs of OSGI with the Specification as well, deriving a common API for both uses. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
