 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 221: JDBCTM 4.0 API Specification
JCP version in use: 2.10 Java Specification Participation Agreement version in use: 2.0 Description: This specification seeks to improve Java application access to SQL data stores by the provision of ease-of-development focused features and improvements at both the utility and API level. Expert Group Transparency: Public Communications Issue Tracking Team
The following information has been updated from the original request.
2013.10.16:
2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.Please use jdbc-spec-discuss@openjdk.java.net
2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?Currently we are using http://bugs.openjdk.java.net.
2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.Files are archived in the "Community Files" under the "Community" tab on this page.2006.10.24: 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.This RI and TCK for this JSR will be delivered as part of RI and TCK for Java SE 6 (JSR 270), respectively. The proposed Java SE 6 licensing terms are available here: http://jcp.org/en/jsr/detail?id=270.2005.09.26: 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)This specification is intended to become part of the Java SE 6 ("Mustang").2.13 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.This JSR will be delivered as part of Java SE 6 "Mustang".Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Original Summary: The JDBC 4.0 API specification seeks to improve Java application access to SQL data stores by the provision of ease-of-development focused features and improvements at both the utility and API level. Using new Java language features planned for JSR-176 Java 2 Standard Edition 1.5, features such as annotations as defined in JSR-175, generics defined in JSR-014 in to addition to supplying a set of JDBC utility classes, SQL savvy developers will be able to more easily access SQL data sources while still benefiting from the full power of the JDBC API. Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Jonathan Bruce E-Mail Address: jonathan.bruce@sun.com Telephone Number: +1 408 276 7029 Fax Number: +1 408 276 7191 Specification Lead: Lance Andersen E-Mail Address: Lance.Andersen@Sun.COM Telephone Number:+1 781 442 2037 Fax Number: +1 781 442 4071 Initial Expert Group Membership: SAP Supporting this JSR: * Oracle Section 2: Request
2.1 Please describe the proposed Specification:The JDBC API is a mature technology, currently in its third revision and has existed in specification format since January 1997. The latest release successfully consolidated the divergent JDBC 2.x generation specifications into one to form the JDBC 3.0 specification. The JDBC 3.0 specification also attended to rounding out the technology to close out gaps and to ensure consistency with the SQL-99 ANSI specifications. In JDBC 4.0, the focus differs. The stated goal of this specification is to provide an improved developer experience while working with relational SQL data stores from the Java platform. To meet this requirement, our primary attention will be given to determining key issues that developers encounter while using the JDBC API and addressing the issues by making adequate provision in the areas detailed below: A set of utility classes will be provided to allow Java applications to JDBC technology enabled applications simpler access to relational datasources. Currently developers rely on rudimentary mechanisms to manage their available datasources, and JDBC technology enabled drivers, in addition to formulating their queries and thereafter managing their connections and processing their results. JDBC 4.0 will specify mechanisms to assist developers in the following categories: * Management of JDBC Technology Enabled Drivers JDBC drivers provide the mechanics to the JDBC API to allow Java applications access to SQL data stores. The introduction of javax.sql.DataSource as a replacement for java.sql.DriverManager was a small step to simplify the manageability of JDBC drivers. JDBC 4.0 seeks to provide utility classes to improve the JDBC driver registration and unload mechanisms. In addition new frameworks will be established to promote easier integration of JDBC technology-enabled drivers into the Java platform. * Connection Management JDBC 3.0 and its predecessors relied primarily on the JDBC URL to define the required data source connection. JDBC 4.0 will specify a mechanism to allow applications to easily get a connection to any data source by simply supplying a set of parameters (host, port etc.) to a standard connection factory mechanism. Attention will also be focused on specifying improved mechanisms to allow the determination of the state of active connections and the ability to easily migrate or specify any connection as standard (non pooled), pooled and even as a distributed connection. It is anticipated that the Meta Data facility (JSR-175) will play a role here to provide the means by which to manipulate and manage active connections, by specifying standard set of tags to control the state of a connection obtained from a JDBC driver or JNDI DataSource.MP< * Statement and Result Processing The JDBC 3.0 specification provides the java.sql.ResultSet as the primary query result processing class. It is flexibile definition allowing for enterprise level relational features including updates, holdability and many other features. JDBC 4.0 will leverage the available J2SE 1.5 language improvements to allow the developer to more closely associate a SQL query with specific data representations such as class representations. It is anticipated that the Meta Data facility (JSR-175) in addition to Generics (JSR-014) facilities will allow a tight association of SQL queries with designated object structures describing query parameters. In a similar linkage, this also allows developers to more immediately tie the results of their queries to designated class definitions and to quickly process a query result. * Persistence and Update mechanisms The JDBC 4.0 specification will investigate the possible alignments and relationships between various persistence mechanisms available for the Java platform. Specification efforts such as Meta Data (JSR-175) and Generics (JSR-014) will provide the means by which standard tags and utilities can be standardized to allow a clearer definition between JDBC and complimentary persistence infrastructures. * Close Association with JDBC RowSet implementations J2SE 1.5 will contain a set of Standard JDBC RowSet implementations as specified in JDBC RowSet Implementations (JSR-114). This specification will provide a set of utiltities described at both the utility class level and the Meta Data language level. This will allow developers to easily migrate JDBC-technology enabled applications towards the JDBC RowSet model that enables disconnected data source access in addition to the ability to manage relational data stores from an XML stand-point. * Maintain focus on SQL control Many developers continue to be comfortable managing SQL code directly from their application. This specification will not unnecessarily mask as developer's ability to manage SQL queries directly from their code base, but it will offers improveds means by which SQL queries and SQL query results can be more closely associated with the Java language and it's underlying specifications. * Ensure JDBC backward compatibility Many applications and deployments have significant investments in the JDBC technology and any improvements to the API, the provision of utility class methods and the ability to utilize meta data facilities and generics will maintain backward compatibility to all previous JDBC specifications. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)JavaTM 2 Platform, Enterprise Edition (J2EE) 1.5 NOTE that this information has been updated from this original request.2.3 What need of the Java community will be addressed by the proposed specification?The Java commuity will benefit from the additional API and utility class improvements that will ease relational data access from the Java platform by leveraging the various languange improvements planned to be introduced into J2SE 1.5. 2.4 Why isn't this need met by existing specifications?Please see 2.1 above. 2.5 Please give a short description of the underlying technology or technologies:Please see 2.1 above. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The specification will be supplied in package format, but to date no decision has been taken on the naming scheme. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?No 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?This specification will build on top of JSR-054, JDBC 3.0 Specification. 2.11 Please describe the anticipated schedule for the development of this specification.This specification will be available towards the end of the calendar year, 2004. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.The EG will use email, weekly conference calls and the private JSR homepage provided as part of the Java Community Process. 2.13 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 as a component of the J2EE 1.5 platform RI and will migrate into the J2SE 1.6 platform RI to form part of the core Java platform. 2.14 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).Does not apply 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Pursuant to the Java Community Process version 2.5, the following is a summary of Sun's anticipated principal license terms and conditions for the JSR
The binary and source for JDBC 4.0 will be made available under the terms and conditions used for the J2SE JRE and SDK. The JDBC 4.0 TCK will be made available under the terms and conditions used for J2SE TCK.
Binaries for J2SE JRE and SDK are licensed, at no charge, under the Sun Microsystems Inc. Binary Code License.
Sources for J2SE SDK (which includes the JRE sources) are licensed, at no charge, under SCSL.
J2SE TCK is made available under SCSL, Attachment E. There is no charge for a TCK license, but there may be a mandatory TCK support fee.
J2SE SDK and TCK sources are made available to Sun's existing TLDA licensees according to their TLDA terms.
J2SE TCK is offered for license at no charge, without support or any trademark license rights, to qualified not-for-profit entities (including not-for-profit academic institutions) and qualified individuals engaged in efforts to create compatible implementations of J2SE specifications
Section 3: Contributions
JSRs:
Other specifications:
3.2 Explanation of how these items might be used as a starting point for the work.The JDBC 3.0 Specification will form the underlying basis for all work anticipated in this proposed specification. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
