Develop Reference

Are two different drivers used while using JDBC-ODBC bridge?

Prior to Java 8 when there was support for type 1 JDBC drivers, were two different drivers used?
The JDBC-ODBC bridge driver included with Java.
ODBC driver for Database System being used, which users need to download and install separately and then configure.

You are correct. The Java app sent queries to the JDBC-ODBC Bridge, which passed them along to the database's ODBC driver, which in turn passed them on to the database itself. The responses followed the same path in the opposite direction.

Rebuilding JRE7 jdbc-odbc bridge for Java 8

Has anyone looked into extracting the jdbc-odbc bridge from an earlier and using it with JRE8 ?
Is it practical / possible to update / improve it to work with Java 8 ?
Would it be legal ?

While this doesn't exactly answer your question, I was hunting for a free JDBC driver for Access, and found UCanAccess. I had success with this particular driver as a replacement while using SquirrelSQL with Access. Seeing as how your question is tagged ms-access, perhaps this might be an acceptable replacement for you.

Questions of this portation's legality aside, Sun's and Oracle's official positions have long been that --
the [JVM-bundled] JDBC-ODBC Bridge should be considered a transitional solution [...] Oracle does not support the JDBC-ODBC Bridge.
However, my employer, OpenLink Software, has produced enterprise-grade commercial Type 1 Bridges between JDBC and ODBC since Java 1.0, and these are fully compatible with the current Java 8 and any ODBC standard-compliant driver, including Microsoft's ODBC driver for Access. You can learn more here --
Single-Tier JDBC-ODBC Bridge Driver -- a JDBC driver for ODBC data sources
Single-Tier ODBC-JDBC Bridge Driver -- an ODBC driver for JDBC data sources

JDBC Driver vs Bridge

I've used JDBC in several applications now to query Derby, PostgreSQL and now MySQL databases. I guess I'm choking on some basic terminology in my attempt to understand what is actually going on underneath the hood. Several terms I've seen batted around:
ODBC
JDBC Driver
Bridge
JDBC-ODBC Bridge
For each of those I did my best to do some digging and gain an understanding of what they are, what they do, and how they relate to one another. I believe I'm about 70% of the way there, I just can't seem to find anything (articesl, blogs, docs, etc.) that tie everything together nicely and confirm my suspicions.
It seems that ODBC is a C library (perhaps a DLL?) that programs can use to communicate with RDBM systems (such as PostgreSQL and MySQL). All queries to these systems flow in and out of this library on a given system.
The JDBC-ODBC bridge is a Java component that contains native code that allows JDBC to communicate with that ODBC library on a given system.
JDBC is a pure Java API for querying RDBM systems.
A JDBC driver (such as a PostgreSQL-JDBC Driver) is where I'm really having trouble. If all RDBM systems follow RDBMS standards, and can communicate with the ODBC library, then why does JDBC need different "drivers" for each of them?
What are these drivers? What do they do? Why are they necessary? Also clarification on any other assertions I've made here would be enormously appreciated. Thanks in advance!

You are almost there. Good question.
What are these drivers: A pure JDBC driver is a driver written in Java, that does not need an ODBC driver to work. You should only use ODBC drivers (through JDBC-ODBC bridge) when you don't have a direct JDBC driver for your database (which is extremely rare, since most {if not all} databases support JDBC nowadays).
A pure JDBC has the advantage of not needing ODBC. ODBC is usually hard to configure, and requires a database native client library to be installed on the system (such as Oracle OCI, or Sybase CT Library).
It used to be the case that ODBC or native drivers were chosen for performance reasons, but I think today pure Java/JDBC perform almost as good as their native/ODBC counterparts.
What do they do: the same as ODBC. A standardized Java API to access relational databases.
Why are they necessary: They are necessary because it simpler to work with them, you just need the JDBC library JAR and your URL connection. Opposed to: native client library + ODBC driver + JDBC-ODBC configuration. It's also the case that every single database has its own network protocol to perform queries against it, and to get results back. So you need one driver for each database vendor. Each one of them implements the specific protocol it needs to connect to its relational database manager. If you were on a world where all database shared the same SQL language and the same communication protocol, you would only need one driver. But that won't happen any time soon.

ODBC and JDBC are equivalent. They both use drivers to transform ODBC (or JDBC) calls into the native database commands. ODBC is older and written in C/C++, while JDBC is written in Java. When JDBC came out, there were no JDBC drivers for most DBs, so they created the JDBC-ODBC driver to allow people to utilize the already available ODBC drivers. This is rarely used now, since almost every DB has a pure Java JDBC driver

Just because DBs use "standard" SQL (and that's in quotes for a reason), does not mean that the DB use the same lower level protocol for communication. SQL is simply a syntax, but not a protocol.
The protocols for Postgres and, say, Oracle are wildly different and offer different features, even though they both use similar SQL features.
SQL itself, while standard, has wide deviations in implementations. MySQL for example is notorious for being less SQL compliant than other DBs. While much SQL used today is portable across DBs, there is much that is not.
JDBC and ODBC are kindred spirits. They provide a shared interface that your application can use to talk to an RDBS. They also provided a common model for vendors to implement. These are the drivers.
Vendors implement a driver to allow a JDBC/ODBC compliant program talk to their database. The drivers task is convert ODBC/JDBC calls in to the appropriate SQL or and other control calls for the database.
The JDBC/ODBC Bridge is a JDBC driver that talks to an existing ODBC driver. It's an abomination. Don't use it. Every database of note today has JDBC drivers. And stick with "type 4" JDBC drivers if at all possible, since these are native Java rather than "type 2" drivers that use JNI to a binary. Buggy type 4 drivers give exceptions, buggy type 2 drivers give JVM crashes which nuke your appserver. No thanks.

You're right; you're very close to having the full picture!
JDBC and ODBC are conceptually very similar. They're both frameworks for interacting with databases. JDBC is Java-specific, while ODBC is Windows-specific. That said, both JDBC and ODBC are actually toothless APIs. In Java terminology, JDBC is actually a set of unimplemented interfaces. While they specify a behavioral contract, they don't inherently know how to talk to any specific database. That's where drivers come in.
Let's talk specifically about JDBC here. JDBC drivers are concrete implementations of the JDBC interfaces that actually know how to talk to an underlying database engine. JDBC guarantees that a ResultSet from the MySQL JDBC driver will behave the same way as a ResultSet from the Postgres JDBC driver.
As others have pointed out, a JDBC/ODBC bridge is just a bit of glue to make code written for JDBC to work with ODBC infrastructure. Generally, that only makes sense if you know with certainty you're writing Java for Windows exclusively; ODBC is Windows-specific, but JDBC is (in theory) cross-platform.

Jdbc is the java way to connect to a database using dricers written in java (since JDBC4).
ODBC is the MS Windows way to connect to a database, these drivers are usually written in C
A JDBC-ODBC Bridge is something rather old, in early days of java there were not all drivers in a JDBC version available, so the build a generic bridge beteween JDBC and already existing ODBC drivers.

Can we use odbc only with java to connect to databases?

Do we always have to use jdbc with Java programs for making connectivity with database or can we use only odbc for connecting to databases with Java programs?

Sun JRE contains a built-in JDBC/ODBC driver (sun.jdbc.odbc.JdbcOdbcDriver). Here's an example how to use it: http://www.javacoffeebreak.com/articles/jdbc/
The driver was removed in Oracle JRE 8, so use Java version 7 or earlier.

You can't use ODBC directly because your JAVA program needs to use the JDBC driver to interact with the Database.

As others have mentioned you can use the JDBC/ODBC bridge driver. (Repeating #Rustam's link here: http://www.javacoffeebreak.com/articles/jdbc/).
There are a couple things to keep in mind when using the JDBC-ODBC bridge. First: it's use was not recommended by Sun for various reasons. The top three implications of using the bridge instead of a proper JDBC driver are:
Not every feature of JDBC is supported. ODBC is a more restrictive API, so some features (like savepoints in transactions) are not supported. However, the most common features like prepared statements are.
The native code to Java runtime translation is much slower than if you were doing everything in Java.
The JDBC/ODBC driver is more fragile than the appropriate JDBC driver. Essentially, if implementers of the ODBC driver don't do things a certain way, the JDBC driver will fail and throw some extra exceptions you might not be able to catch. In particular, you will be more susceptible to memory leaks. If you aren't building a long running service you might be OK.
That said, the JDBC/ODBC driver will work for a database that does not have direct JDBC support (most major databases do). Sometimes you don't need all those fancy features and just want to throw something together quickly. The JDBC/ODBC driver is designed for that.

Short answer : NO.
ODBC ( Open Database Connectivity ) hides the details of what database you are talking to. It has nothing to do with Java. If java programs need to talk to the database, then they have to interact with ODBC drivers. To interact with ODBC drivers, you need JDBC-ODBC drivers which hides the details of how the communication happens. You can pretty much make a few method calls and all set to go. The power of abstraction.

You can use JDBC-ODBC drivers

My understanding is that you would not want to - it would become tedious and error prone when things dont go perfectly.
I.E. you can't catch an exception when/if you invoke a non java DLL from inside java.

What is the JDBC equivalent to query an IBM Domino data store?

I need to query an IBM Domino data store that was populated using Lotus Notes from within a Java application. I am hoping that IBM followed the JDBC design pattern so that I can implement similarly to what I have done to get data from Oracle. Where should I start?
I am aware that IBM does not support JDBC for Domino. What I need is an equivalent.

Searching Google for "java lotus notes jdbc" yields this note from IBM:
Question
Is Lotus® Domino® Driver for JDBC (LDDJ) supported on current versions of IBM® Lotus Notes® and Lotus Domino?
Answer
IBM no longer provides a Notes JDBC driver since Java developers may utilize the Notes.jar to make API calls into Notes databases. The Notes JDBC driver is no longer provided nor supported.

This really is no true equivalent to a JDBC driver if by that you mean something that works in a similar way. The sql style interface provided by NotesSQL and the JDBC driver was always severely limited.
To directly interact with the data with java you need to use the Notes java api using Notes.jar (local) or NCSO.jar (remote IIOP). This gives you a notes style access to the data. Your data is organized as databases of documents containing items. The documents are indexed into views and an individual document can be indexed by multiple views. There are also various built in search facilities.
If you just need to provide external access to a relatively fixed query a web service built into the application is a good way to go. Internally this would use the native notes api (java or lotusscript) and you'd probably want to get the developer of the database o do that for you.
If you really need to have free access to the data and want to query it with SQL you will have to export it to an RDBMS through a number of tools and some of these can keep your data in sync. Since there is no generic way to look at Notes data as simple tables you need to configure this export to match the application requirements.

Lotus Notes/Domino isn't really an equivalent data store to something like Oracle, so finding something to slot into your existing solution could be tricky. As matt b suggested, you could try using the Notes Java api supplied by notes (You should be able to get this from a notes client install). Another option is to use the wrapper api Domingo which takes some of the edges off notes.jar (which is itself a wrapper for the C apis).
A simpler option might be to use http and xml (assuming you only want to read data(?)). If you enable http on the domino server, you can get xml data out of views.
http://www.yourserver.com/db.nsf/viewname?readviewentries
Salgiza's answer to this question has more detail on this.

Lotus Notes JDBC Driver might answer some of your questions.

Lotus Notes is not a relational database, I do recall from some time ago, they started supporting java instead of lotus script, there is a good chance that they support an external java API.
According to wikipedia:
External to the Lotus Notes
application, IBM provides toolkits in
C, C++, and Java to connect to the
Domino database and perform a wide
variety of tasks. The C toolkit is the
most mature and the C++ toolkit is an
objectized version of the C toolkit,
lacking many functions the C toolkit
provides. The Java toolkit is the
least mature of the three and can be
used for basic application needs.
So if you can get your hands on a toolkit you should be ready to roll.
I noticed on the toolkit page that they support an odbc driver,
so you should be able to use the jdbc-odbc bridge.

OpenNTF have released a JDBC driver see: JDBC Access for IBM Lotus Domino

Sun & Son www.sunandson.com have just put their Notes JDBC Driver through 12 months of IBM certification - this is a fully supported product - and has been Cognos JDBC certified
DBC Driver for Notes will be supported in Cognos Q3 - 10.2.1 Fix Pack 4
and then in Q4 - it will be in the main point release 10.2.2
Here are a few things to keep in mind about the DomSQL driver:
The client component is pure Java code, so it should run on any platform
The server component, which runs on the Domino server, includes some C code
The upcoming release of the Data Modeler provides seamless integration of the DomSQL driver and a new Metadata Library module, which aggregates all of the Data Modeler metadata definitions across the enterprise.
Although there is an open version of the DomSQL driver available for download from the OpenNFT.org site, the Sun & Son enhanced DomSQL driver has gone through the Cognos certification process and is the only version that will work with Cognos.

There is a NEW JDBC Driver for IBM Notes Domino that is IBM Certified http://www-304.ibm.com/partnerworld/gsd/solutiondetails.do?solution=51151&expand=true&lc=en