🚀 go-pugleaf

JSR 221 
JDBC 4.0 API Specification 
 
 
Print Format
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 impr
ovements at both the utility and API level. Using new Java language features p
lanned for JSR-176 Java 2 Standard Edition 1.5, features such as annotations a
s 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 easil
y access SQL data sources while still benefiting from the full power of the JD
BC API. 
Specification Lead
Jonathan Bruce 
Sun Microsystems, Inc. 
Expert Group
BEA Systems   Berlin, Volker 
DataDirect Technologies   IBM 
MySQL Inc.   New Atlanta Communications, LLC 
Nokia Corporation   Oracle 
Pramati Technologies   SAP AG 
Sun Microsystems, Inc.   Sybase 
I would like to join this Expert Group. 
Private Expert Group homepage  
Status
Expert Group Formation   10 Jun, 2003  
JSR Review Ballot   09 Jun, 2003 
Java Community Process version in use: 2.5 
Java Specification Participation Agreement version in use: 2.0
Please direct your comments on this JSR to jsr-221-comments@jcp.org 
Original Java Specification Request (JSR)
Identification | Request | Contributions | Additional Information 
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: Jonathan Bruce
E-Mail Address: jonathan.bruce@sun.com
Telephone Number:+1 408 276 7029
Fax Number: +1 408 276 7191
Initial Expert Group Membership: 
SAP 
Supporting this JSR: 
* Oracle
* DataDirect Technologies
* BEA
* Fujitsu
* MySQL
* INET Software
* Novell
* Borland
* Pointbase Inc.
* Macromedia
* SAP
Section 2: Request
2.1 Please describe the proposed Specification:
The JDBC API is a mature technology, currently in its third revision and has e
xisted in specification format since January 1997. The latest release successf
ully 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 t
he SQL-99 ANSI specifications.
In JDBC 4.0, the focus differs. The stated goal of this specification is to pr
ovide 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 ar
eas detailed below:
A set of utility classes will be provided to allow Java applications to JDBC t
echnology enabled applications simpler access to relational datasources. Curre
ntly developers rely on rudimentary mechanisms to manage their available datas
ources, 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 categ
ories:
* 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 repla
cement for java.sql.DriverManager was a small step to simplify the manageabili
ty of JDBC drivers. JDBC 4.0 seeks to provide utility classes to improve the J
DBC driver registration and unload mechanisms. In addition new frameworks will
 be established to promote easier integration of JDBC technology-enabled drive
rs into the Java platform.
* Connection Management
JDBC 3.0 and its predecessors relied primarily on the JDBC URL to define the r
equired data source connection. JDBC 4.0 will specify a mechanism to allow app
lications 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 th
e determination of the state of active connections and the ability to easily m
igrate or specify any connection as standard (non pooled), pooled and even as 
a distributed connection. It is anticipated that the Meta Data facility (JSR-1
75) will play a role here to provide the means by which to manipulate and mana
ge active connections, by specifying standard set of tags to control the state
 of a connection obtained from a JDBC driver or JNDI DataSource.MP< * Statemen
t and Result Processing
The JDBC 3.0 specification provides the java.sql.ResultSet as the primary quer
y result processing class. It is flexibile definition allowing for enterprise 
level relational features including updates, holdability and many other featur
es. JDBC 4.0 will leverage the available J2SE 1.5 language improvements to all
ow the developer to more closely associate a SQL query with specific data repr
esentations such as class representations. It is anticipated that the Meta Dat
a 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 i
mmediately tie the results of their queries to designated class definitions an
d to quickly process a query result.
* Persistence and Update mechanisms
The JDBC 4.0 specification will investigate the possible alignments and relati
onships between various persistence mechanisms available for the Java platform
. Specification efforts such as Meta Data (JSR-175) and Generics (JSR-014) wil
l provide the means by which standard tags and utilities can be standardized t
o allow a clearer definition between JDBC and complimentary persistence infras
tructures.
* Close Association with JDBC RowSet implementations
J2SE 1.5 will contain a set of Standard JDBC RowSet implementations as specifi
ed 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 d
ata 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 the
ir application. This specification will not unnecessarily mask as developer's 
ability to manage SQL queries directly from their code base, but it will offer
s improveds means by which SQL queries and SQL query results can be more close
ly associated with the Java language and it's underlying specifications.
* Ensure JDBC backward compatibility
Many applications and deployments have significant investments in the JDBC tec
hnology and any improvements to the API, the provision of utility class method
s and the ability to utilize meta data facilities and generics will maintain b
ackward compatibility to all previous JDBC specifications.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedd
ed, card, etc.)
JavaTM 2 Platform, Enterprise Edition (J2EE) 1.5
2.3 What need of the Java community will be addressed by the proposed specific
ation?
The Java commuity will benefit from the additional API and utility class impro
vements that will ease relational data access from the Java platform by levera
ging 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 technologi
es:
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 operatin
g 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 secu
rity model?
No
2.9 Are there any internationalization or localization issues?
No
2.10 Are there any existing specifications that might be rendered obsolete, de
precated, 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 spec
ification.
This specification will be available towards the end of the calendar year, 200
4. 
2.12 Please describe the anticipated working model for the Expert Group workin
g on developing this specification.
The EG will use email, weekly conference calls and the private JSR homepage pr
ovided 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 p
rofile or platform edition, or stand-alone, or both. Include version informati
on 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 o
f the core Java platform. The TCK will be made available as a component of the
 J2EE 1.5 platform TCK (CTS) and will migrate into the J2SE 1.6 platform TCK (
JCK) 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 pro
file 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 , JDB
C, version 4.0.
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 availa
ble under the terms and conditions used for J2SE TCK.
Binaries for J2SE JRE and SDK are licensed, at no charge, under the Sun Micros
ystems Inc. Binary Code License.
Sources for J2SE SDK (which includes the JRE sources) are licensed, at no char
ge, 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 a
ccording 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-profi
t academic institutions) and qualified individuals engaged in efforts to creat
e compatible implementations of J2SE specifications
Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations tha
t describe the technology. Please include links to the documents if they are p
ublicly available.
JSRs:
* JSR 014 Add Generic Types to the JavaTM Programming Language
* JSR-012 Java Data Objects (JDO)
* JSR 054 JDBC 3.0 Specification
* JSR 112 Connectors 1.5
* JSR 114 JDBC RowSet Implementrations
* JSR 153 Enterprise JavaBeans 2.1
* JSR 175 A Metadata Facility for the JavaTM Programming Language
* JSR 201 Extending the JavaTM Programming Language with Enumerations, Autobox
ing, Enhanced for loops and Static Import
Other specifications:
* JDBC 1.22 API Specification - http://java.sun.com/products/jdbc/download2.ht
ml
* JDBC 2.1 API Specification - http://java.sun.com/products/jdbc/download.html

* JDBC 2.0 Optional Package API - http://java.sun.com/products/jdbc/download.h
tml
3.2 Explanation of how these items might be used as a starting point for the w
ork.
The JDBC 3.0 Specification will form the underlying basis for all work anticip
ated in this proposed specification.
Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Membe
r wishes to include in the JSR.
No additional information.
--
No problem???

�� ��Դ:��Ʈ��ˮ�Ƽ� Freecity.dhs.org��[FROM: matianyi]