Printed: Jun 19, 2013
|Craig Russell||Sun Microsystems, Inc.|
|Adams, Matthew T.||akquinet tech@spree||Bobzin, Heiko|
|Ericsson Inc.||Garulli, Luca||IBM|
|Informix Software||Lawson Software||McClure, Martin|
|Objectivity, Inc.||Oracle||Plotnikov, Constantine|
|Progress Software||Rational Software||Roos, Robin|
|SAP AG||Secant Technologies, Inc.||Silverstream Software|
|Software AG||Sun Microsystems, Inc.||Suraparaju, Rajesh Babu|
Original Java Specification Request (JSR)
Identification | Request | Contributions
Section 1: Identification
The primary contact for this submission is:
Sun Microsystems, Inc.
901 San Antonio Road UMPK16-304, Palo Alto, CA 94303 USA
phone: +1 650 786-7819
The contact information for the other companies who endorse this JSR is:
IONA Technologies Inc.
60 Aberdeen Ave. Cambridge, MA 02138 USA
phone: +1 617 949 4122
300 Lakeside Drive, Suite 2700, Oakland, CA 94612 USA
phone: +1 510 628-3739
6475 Christie Ave, Emeryville, CA 94608 USA
phone: +1 510 922-3500
Inline Software, Inc.
751 Miller Drive SE Suite E3, Leesburg, VA 20175 USA
phone: +1 703 737-7750
fax: 1 + 703 737-0110
San Francisco, CA USA
phone: +1 415 659-2600
Ardent Software Inc.
1099 18th Street, Suite 2500 Denver, CO 80202 USA
phone: +1 303 313 3133
Object Design Inc.
25 Burlington Mall Road Burlington, MA 01803-4194 USA
301B E. Evelyn Avenue Mountain View CA 94041-1530 USA
phone: +1 650 254 7113
Gemstone Systems, Inc.
15400 NW Greenbrier Parkway Suite 280, Beaverton, OR 97006 USA
phone: +1 503 533-3600
Secant Technologies Inc.
4853 Galaxy Parkway, Suite S Cleveland, OH 44128 USA
phone: +1 216 595 3830
7001 Development Drive, Research Triangle Park, NC 27709
Advanced Language Technologies
2030 Main Street, Suite 530, Irvine, CA 92614
Baan Company - Tech@Spree Software Technology GmBH
Buelowstr. 66, 10783 Berlin Germany
Phone: +49-(0)-30 235 520 0
Computer Associates International, Inc.
Route 206 and Orchard Road, Princeton, NJ 08543-0008 USA
1300 Godward Street, Minneapolis, MN 55413-3004
Jeff Eastman Windward Solutions, Inc.
395 W. El Camino Real, Sunnyvale, CA 94087
phone: +1 408 523 5811
6539 Dumbarton Circle, Fremont, CA 94555
Am Siepbach 9, D-41564 Kaarst, Germany
phone: +184.108.40.2066-3 00
phone: +1-650- 286-4640
Section 2: Request
All Java platforms, including desktop, server, personal, embedded, and card, can use this API to access data.
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 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.
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:
The working name for the package is javax.jdo. This name is subject to a better proposal during the life of the project.
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.
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 of implementations are not required, nor are they proscribed by this specification.
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.
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.