• JDBC 1.0 was designed to provide basic functionality with an emphasis on ease of use.
• JDBC 2.0 offered more advanced features and server-side capabilities.
• JDBC 3.0 "rounded out" the API by providing performance optimization. It added improvements in the areas of connection pooling, statement pooling, and provided a migration path to Sun Microsystems' connector architecture.

The optional features in JDBC 2.0 (such as connection and distributed transactions) are now required features in JDBC 3.0, along with the new features in JDBC 3.0, such as prepared statement pooling.

Today, there are four types of JDBC drivers in use:

• Type 1: JDBC-ODBC bridge, plus an ODBC driver
• Type 2: native API, part-Java driver
• Type 3: pure Java driver for database middleware
• Type 4: pure Java driver for direct-to-database

Type 3 and Type 4 JDBC drivers are both pure Java drivers, and therefore, offer the best performance, portability, and range of features for Java developers.

Type 1
A Type 1 JDBC driver is a JDBC-ODBC Bridge, plus an ODBC driver. Sun Microsystems recommends using Type 1 drivers for prototyping only and not for production purposes. The bridge driver is provided by Sun without support to developers and is intended to support legacy products. When a major patch is required, Sun provides it, but they do not provide end-user support for this software. Typically, the bridge is used when there is already an investment in ODBC technology, such as in Windows application servers.

Sun Microsystems provides a JDBC-ODBC Bridge driver, but because ODBC loads binary code and database client code on the client using the bridge, this technology isn't suitable for a high-transaction environment. Type 1 drivers also don't support the complete Java command set and are limited by the functionality of the ODBC driver.

Type 2
A Type 2 JDBC driver is a native-API, part-Java driver. Type 2 drivers are used to convert JDBC calls into native calls of the major database vendor APIs. These drivers suffer from the same performance issues as Type 1 drivers, namely binary-code client loading, and they are platform-specific.

Type 2 drivers force developers to write platform-specific code, something no Java developer really wants to do. But, because large database vendors, such as Oracle and IBM, use Type 2 drivers for their enterprise databases, developers who use these drivers must keep up with different driver releases for each database vendor's product release and each operating system.

Also, because Type 2 drivers don't use the full Java API, developers find themselves having to perform additional configuration when connecting Java applications to data sources. Often, Type 2 drivers aren't architecturally compatible with mainframe data sources, and when they are, they are less than ideal.

For these reasons and others, most Java database developers opt for either Type 3 or the newer and more flexible Type 4 pure Java JDBC drivers.

Figure 1. The Architectural Difference Between Type 1 and Type 2 Drivers. While Type 1 JDBC drivers offer convenience of access to ODBC data sources, they are limited in their functionality and performance. Type 2 JDBC drivers are OS-specific and compiled, and although they offer more Java functionality and higher performance than Type 1 drivers, still require a controlled environment. Figure courtesy of Sun Microsystems.

Type 3
Type 3 JDBC drivers are pure Java drivers for database middleware. JDBC calls are translated into a middleware vendor's protocol, and the middleware converts those calls into a database's API. Type 3 JDBC drivers offer the advantage of being server-based, meaning that they do not require native client code, which makes Type 3 drivers faster than Type 1 and Type 2 drivers. Developers can also use a single JDBC driver to connect to multiple databases.

Type 4
Type 4 JDBC drivers are direct-to-database pure Java drivers ("thin" drivers). A Type 4 driver takes JDBC calls and translates them into the network protocol (proprietary protocol) used directly by the DBMS. Thus, client machines or application servers can make direct calls to the DBMS server. Each DBMS requires its own Type 4 driver; therefore, there are more drivers to manage in a heterogeneous computing environment, but this is outweighed by the fact that Type 4 drivers provide faster performance and direct access to DBMS features.

Figure 2. The architectural difference between Type 3 and Type 4 drivers. Type 3 drivers leverage the advantages of middleware products to supply heterogeneous database access, and are a strong server-side solution when that middleware product runs on a single OS. Type 4 drivers provide fast and powerful direct access from Java clients to the databases themselves, but do not provide some of the server-side OS optimization found in Type 3 drivers. Figure courtesy of: Sun Microsystems.