JDBC is the technology Java applications use to connect to relational databases and other data sources. Sun claim that JDBC doesn't stand for Java Database Connectivity but I've never seen it used for connecting to anything else. The technology was introduced very early on in the development of Java (I remember using it with 1.1) and so has had time to mature. It is, I think it is safe to say, one of the really big wins of Java. Connecting to a database is very simple and reliable and for the most part transparent. JDBC has grown with Java and offers a host of features that make interacting with databases a pleasure rather than a chore.
Using JDBC is simple but there is a surprising amount going on behind the scenes to make this simplicity work. The problem is that JDBC aims to present the end user with a platform neutral view of a database while also providing the user the ability to access all of the underlying databases power. This conflict of interests, being both generic and specific, is handled extremely well by the JDBC architecture and only becomes apparent when coding very close to the edge of the specification.
Connecting to a database is carried out via adatabase driver. These have grown in maturity now to the point where it really couldn't be simpler. There are four types of driver but only type 3 and 4 are worth using.
Type 1 connections use a generic driver that knows how to connect to ODBC (the open database connector). This generic driver is veyr limited in scope and slow. If all else fails this driver can be used but in reality it's just not worth the hassle. Set up is on a per-machine basis and, in my experience, breaks as soon as you look at it.
Type 2 connections use a native API for connecting to the database. This type of connector requires the native API to be installed correctly on the client machine. This method can be quite fast but it is also a per-machine solution. If there is a type 3 or 4 driver use that rather than this.
Type 3 connectors are fairly rare. These connect, over a network, to a server that than passes the request on to the database. The middleware provides translation of the database neutral request into a dialect the database understands and vice-versa. The problem with this solution is that it isn't really any simpler than type 4 and requires the middleware to be running somewhere.
Type 4 connectors are the simplest to use but the hardest to write. Fortunatly most databases come with type 4 connectors. These translate the generic call to the database into a native call directly giving maximum performace with minimum overhead. Everything you need to access the database is contained in one driver package so reliability is good.