JDBC driver implementations vary because of the wide variety of operating systems and hardware platforms in which Java operates. Sun has divided the implementation types into four categories  known as: 

• JDBC-ODBC bridge plus ODBC driver, also called Type 1.
• Native-API, partly Java driver, also called Type 2.
• JDBC-Net, pure Java driver, also called Type 3.
• Native-protocol, pure Java driver, also called Type 4.

Type 1 Driver- the JDBC-ODBC bridge 

In a Type 1 driver, a JDBC bridge is used to access ODBC drivers installed on each client machine. Using ODBC requires configuring on your system a Data Source Name (DSN) that represents the target database.  When Java first came out, this was a useful driver because most databases only supported ODBC access but now this type of driver is recommended only for experimental use or when no other alternative is available.

The JDBC type 1 driver, also known as the JDBC-ODBC bridge is a database driver implementation that employs the ODBC driver to connect to the database. The driver converts JDBC method calls into ODBC function calls. The bridge is usually used when there is no pure-Java driver available for a particular database.

The driver is implemented in the sun.jdbc.odbc.JdbcOdbcDriver class and comes with the Java 2 SDK, Standard Edition. The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the operating system.

Type 1 is the simplest of all but platform specific i.e only to Microsoft platform.

Type 1 drivers are “bridge” drivers. They use another technology such as Open Database Connectivity (ODBC) to communicate  with a database. This is an advantage because ODBC drivers exist for many Relational Database Management System (RDBMS) platforms. 

Functions: 

1.  Translates query obtained by JDBC into corresponding ODBC query, which is then handled by the ODBC driver. 
2.  Sun provides a JDBC-ODBC Bridge driver. sun.jdbc.odbc.JdbcOdbcDriver. This driver is native code and not Java, and is closed
    source.
3. Client -> JDBC Driver -> ODBC Driver -> Database
4. There is some overhead associated with the translation work to go from JDBC to ODBC.

Advantages:

Almost any database for which ODBC driver is installed, can be accessed.

Disadvantages: 

1. Performance overhead since the calls have to go through the JDBC overhead bridge to the ODBC driver, then to the native database connectivity interface.
2. The ODBC driver needs to be installed on the client machine.
3. Considering the client-side software needed, this might not be suitable for applets.

Type 2 Driver – the Native-API Driver

The JDBC type 2 driver, also known as the Native-API driver is a database driver implementation that uses the client-side libraries of the database. The driver converts JDBC method calls into native calls of the database API.

A native-API partly Java technology-enabled driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.  It does not have the overhead of the additional ODBC function calls.

Functions: 

1. This type of driver converts JDBC calls into calls to the client API for that database.
2. Client -> JDBC Driver -> Vendor Client DB Library -> Database

Advantage

Better performance than Type 1 since no jdbc to odbc translation is needed.

Disadvantages

1. The vendor client library needs to be installed on the client machine.
2. Cannot be used in internet due the client side software needed.
3. Not all databases give the client side library.

Type 3 Driver – the Network-Protocol Driver

The JDBC type 3 driver, also known as the network-protocol driver is a database driver implementation which makes use of a middle-tier between the calling program and the database. The middle-tier (application server) converts JDBC calls directly or indirectly into the vendor-specific database protocol.

This differs from the type 4 driver in that the protocol conversion logic resides not at the client, but in the middle-tier. However, like type 4 drivers, the type 3 driver is written entirely in Java.  These drivers use a networking protocol and middleware to communicate with a server. The server then translates the protocol to DBMS function calls specific to DBMS.

Functions: 

1. Follows a three tier communication approach.
2. Can interface to multiple databases – Not vendor specific.
3. The JDBC Client driver written in java, communicates with a middleware-net-server using a database independent  protocol, and then this net server translates this request into database commands for that database.
4. Thus the client driver to middleware communication is database independent.
5. Client -> JDBC Driver -> Middleware-Net Server -> Any Database

Advantages

1. Since the communication between client and the middleware server is database independent, there is no need for the vendor db library on the client machine. Also the client to middleware need’nt be changed for a new database.
2. The Middleware Server (Can be a full fledged J2EE Application server) can provide typical middleware services like caching (connections, query results, and so on), load balancing, logging, auditing etc..
3. eg. for the above include jdbc driver features in Weblogic.
4. Can be used in internet since there is no client side software needed.
5. At client side a single driver can handle any database.(It works provided the middlware supports that database!!)

Disadvantages

1. Requires database-specific coding to be done in the middle tier.
2.  An extra layer added may result in a time-bottleneck. But typically this is overcome by providing efficient middleware
     services described above.

Type 4 Driver – the Native-Protocol Driver

The JDBC type 4 driver, also known as the native-protocol driver is a database driver implementation that converts JDBC calls directly into the vendor-specific database protocol.

The type 4 driver is written completely in Java and is hence platform independent. It is installed inside the Java Virtual Machine of the client. It provides better performance over the type 1 and 2 drivers as it does not have the overhead of conversion of calls into ODBC or database API calls. Unlike the type 1 and 2 drivers, it does not need associated software to work.

A native-protocol fully Java technology-enabled driver converts JDBC technology calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress.

The IBM Toolbox for Java JDBC driver is a Type 4 JDBC driver, indicating that the API is a pure Java networking protocol driver.

Functions

1. Type 4 drivers are entirely written in Java that communicate directly with a vendor’s database through socket connections. No translation or middleware layers, are required, improving performance.
2. The driver converts JDBC calls into the vendor-specific database protocol so that client applications can communicate directly with the database server.
3. Completely implemented in Java to achieve platform independence.
4. e.g include the widely used Oracle thin driver – oracle.jdbc.driver. OracleDriver which connect to jdbc:oracle:thin URL format.
5. Client Machine -> Native protocol JDBC Driver -> Database server

Advantages

These drivers don’t translate the requests into db request to ODBC or pass it to client api for the db, nor do they need a middleware layer for request indirection. Thus the performance is considerably improved.

Disadvantage

At client side, a separate driver is needed for each database.