Java database connectivity (JDBC) is JavaSoft specification of a standard application programming interface (API) that allows Java programs to access database management systems. The JDBC API consists of a set of interfaces and classes written in the Java programming language. Using these standard interfaces and classes, programmers can write applications that connect to databases, send queries written in structured query language (SQL), and process the results. JDBC is oriented towards relational databases.
Because JDBC is a standard specification, a Java program that uses the JDBC API can connect to any database management system (DBMS) for which there is a JDBC driver.
The JDBC API defines the Java interfaces and classes that programmers use to connect to databases and send queries.
A Java program (that uses the JDBC API) loads the specified driver for a particular DBMS before it actually connects to a database. The JDBC’s DriverManager class then sends all JDBC API calls to the loaded driver.
Types of JDBC Drivers
There are 4 different types of JDBC drivers:
- Type 1 : JDBC-ODBC bridge driver
- Type 2 : Native-API Driver
- Type 3 : All Java + Middleware translation driver
- Type 4 : Pure Java driver
Let’s look at them one by one.
Type 1 : JDBC-ODBC bridge driver
A type 1 JDBC driver consists of a Java part that translates the JDBC interface calls to ODBC calls. An ODBC bridge then calls the ODBC driver of the given database i.e. the driver converts JDBC method calls into ODBC function calls. The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the underlying operating system the JVM is running upon. Also, use of this driver leads to other installation dependencies; for example, ODBC must be installed on the computer having the driver and the database must support an ODBC driver. The use of this driver is discouraged if the alternative of a pure-Java driver is available.
Sun provides a JDBC-ODBC Bridge driver: sun.jdbc.odbc.JdbcOdbcDriver. This driver is native code and not Java, and is closed source.
Type 2 : Native-API Driver
A type 2 JDBC driver is like a type 1 driver, except the ODBC part is replaced with a native code part instead. The native code part is targeted at a specific database product i.e. uses the client-side libraries of the database product. The driver converts JDBC method calls into native calls of the database native API.
This architecture eliminated the need for the ODBC driver and instead directly called the native client libraries shipped by the database vendors. This was quickly adopted by the DB vendors as it was quick and inexpensive to implement since they could reuse the existing C/ C++ based native libraries.
Type 3 : All Java + Middleware translation driver
A type 3 JDBC driver is an all Java driver that sends the JDBC interface calls to an intermediate server. The intermediate server then connects to the database on behalf of the JDBC driver. The middle-tier (application server) converts JDBC calls directly or indirectly into the vendor-specific database protocol.
Type 3 drivers sought to be a 100% Java solution but never really gained much traction. Type 3 drivers had a Java client component and a Java server component, where the latter actually talked to the database. Although this was technically a full Java solution, the database vendors did not like this approach as it was costly – they would have to rewrite their native client libraries which were all C/C++. In addition, this didn’t increase the architectural efficiency as we are really still a 3 tier architecture so it is easy to see why this was never a popular choice.
Type 4 : Pure Java driver
The JDBC type 4 driver, also known as the Direct to Database Pure Java Driver, is a database driver implementation that converts JDBC calls directly into a vendor-specific database protocol. It is implemented for a specific database product. Today, most JDBC drivers are type 4 drivers.
Written completely in Java, type 4 drivers are thus platform independent. They install inside the Java Virtual Machine of the client. This provides better performance than the type 1 and type 2 drivers as it does not have the overhead of conversion of calls into ODBC or database API calls. Unlike the type 3 drivers, it does not need associated software to work.
This architecture encapsulates the entirety of the JDBC API implementation along with all the logic for communicating directly with the database in a
single driver. This allows for easy deployment and streamlines the development process by having a single tier and a small driver all in a 100% java package.
This type includes, for example, the widely used Oracle thin driver.
Happy Learning !!