JDBC
In the beginning, there was JDBC v1.0. Although initially introduced as an addendum to JDK 1.02, it was standardized as part of JDK 1.1 as the classes and interfaces that make up the java.sql package. It remains an integral part of J2SE 1.3. In an effort to unravel JDBC's family tree, Table 8.4 lists the versions of JDBC, J2SE (previously JDK), and J2EE.
| JDBC | J2SE (JDK) | J2EE | Package | Significant Features/Notes |
|---|---|---|---|---|
| JDBC 1.0 | JDK 1.1 | N/A | java.sql | DriverManager, Connection, Statement, ResultSet Note: Formalized in JDBC 1.2 Spec. |
| JDBC 2.1 Core API | J2SE 1.2 | J2EE 1.2 J2EE 1.3 | java.sql | Scrollable and updateable ResultSets
Batch updates SQL1999 data types (BLOB, CLOB, ARRAY, Structured Type, REF) Mapping SQL UDTs to Java classes Direct storing of Java objects Note: When first introduced, was called the JDBC 2.0 Core API, not 2.1. |
| JDBC 2.0 Optional Package | J2EE 1.2 J2EE 1.3 | javax.sql | DataSource, ConnectionPoolDataSource, XADataSource
JNDI support Rowsets Note: When first introduced, was called the JDBC 2.0 Standard Extension API. | |
| JDBC 3.0 | J2SE 1.4 | J2EE 1.4 | java.sql javax.sql | Unifies JDBC 2.1 Core API and JDBC 2.0 Optional Package
More thorough support for SQL1999 data types DATALINK/URL data type (external data) Savepoint support Retrieval of auto-generated keys Multiple open result sets Define relationship to Connector architecture Numerous other minor enhancements |
The JDBC 2.1 Core API is included in J2SE 1.2 and also in J2EE 1.2 and J2EE 1.3 platforms. J2EE 1.2 and J2EE 1.3 also require the JDBC 2.0 Optional Package. If all these different versions aren't confusing enough, you may occasionally see documentation that refers to the “JDBC 2.0 API.” This refers to the combination of (what is now called) the JDBC 2.1 Core API and JDBC 2.0 Optional Package. So, J2EE 1.2 and 1.3 effectively mandate the JDBC 2.0 API.
However, sanity is about to break out! At the time of writing, JDBC 3.0 was just coming out of draft, to be part of J2SE 1.4. This unifies both the Core API and the optional package. Given than J2SE 1.4 will include JDBC 3.0, it will also implicitly be part of J2EE 1.4.
One notable feature about JDBC 3.0 is that it consolidates support for SQL1999 abstract data types. Support for these was introduced in JDBC 2.1 Core API, when SQL1999 was still in draft and was called SQL3. Now that SQL1999 is a ratified standard, JDBC 3.0 has added some features that were, by necessity, previously omitted.
You can learn more about JDBC 3.0 (and download its specification) at http://java.sun.com/products/jdbc/index.html.
The abstract data types defined by SQL1999 are as follows:
BLOBs are binary large objects. These can literally store anything, such as a JPEG image, a recording, a Java serialized object, and so on. BLOBs are transparently accessed using SQL Locators. The BLOB data isn't stored along with the rest of the row; instead, a pointer is held. While this marginally slows down access, it means that BLOBs can have very large size limits (2Gb or more).
The JDBC ResultSet.getBlob() method and the Blob interface provide access to data stored in BLOB columns.
CLOBs are character large objects, similar to BLOBs except that the data is treated as characters; as a result, conversion of data between locales is performed. CLOBs are also transparently accessed via SQL Locators.
The JDBC ResultSet.getClob() method and the Clob interface provide access to data stored in CLOB columns.
SQL structured types are a mechanism to allow user-defined data types to be defined. They are somewhat similar to a class in Java that has only public fields. The following SQL1999 command defines a structured type called XY_POINT:
CREATE TYPE XY_POINT AS (X FLOAT, Y FLOAT) NOT FINAL
SQL1999 allows columns to be defined of these types, and also allows tables to be defined consisting of instances of these types. Defining a table from a structure type is done using SQL syntax such as the following:
CREATE TABLE SCATTER_GRAPH OF XY_POINT (REF OID IS SYSTEM GENERATED);
The OID is an identifier to a row in this table. The JDBC ResultSet.getObject() method and the Struct interface provide access to data stored in structured type columns (not structured type tables). To simplify implementation, custom mappings can be defined to convert the data of the SQL structured type to a Java class. This is somewhat akin to implementing the java.io.Externalizable interface for the target Java class; java.sql.SQLData interface is the actual interface that must be implemented.
ARRAYs provide the ability to store vector data. In the case study, the Applicant table defines two columns—address1 and address2. Using SQL1999 types, these could instead be defined to be a single ARRAY column. Usually ARRAYs are accessed via SQL Locators, although it is possible for the data to be stored along with the rest of the data on the row.
The JDBC ResultSet.getArray() method and the Array interface provide access to data stored in ARRAY columns.
REFs are a persistent pointer to an instance of a SQL structured type, defined when a table is created from an SQL structured type. You might think of them as an SQL1999 equivalent to a foreign key.
The JDBC ResultSet.getRef() method and the Ref interface provide access to the SQL REF. This reference can be used to access data held in a table defined to be of a structured type (such as SCATTER_GRAPH). This is the way that data stored in structured type tables can be accessed.
These data types may be unfamiliar to you; after all, many RDBMS do not support them yet. However, JDBC 3.0 includes support for these data types because the JDBC specification authors expect RDBMS support for them will have become widespread within the next five years or so.
That said, there is some overlap in intent between SQL1999 data types and the objectives of SQLj. If SQLj proves more popular (because it is rooted more on Java technology rather than SQL), it could be that Java's popularity may decelerate the adoption of SQL1999 data types. Only time will tell. So, high time to look at this next technology, SQLj.