JDBC stands for Java Database Connectivity. It is an application programming interface (API) for Java for connecting to and using databases.
JDBC is included in the JDK 1.1.x release.
A detailed description of changes in the JDBC API is available from JavaSoft's website.
Furthermore, because of security restrictions imposed on untrusted applets, the JDBC from JavaSoft classes cannot be loaded over a network by Netscape and Microsoft (which do not yet support JDK 1.1). These browsers will not load classes claiming to be part of packages under the java.* tree. To circumvent this problem, some JDBC driver developers have re-compiled the JDBC package under a different name (for example, Symantec uses symjava.sql.* instead of java.sql.* for dbANYWHERE).
It is installed along with JDK 1.1. It is also included as part of MS SDK for Java 2.0 (currently in alpha) and a number of other development kits. Once the development kit of your choice is installed correctly, you should be able to use JDBC.
Considering the amount of support in the Java community for JDBC, it is not advisable to seek alternative solutions. Nevertheless, there are some alternatives to JDBC.
Microsoft's Java VM, which is shared by JVIEW.EXE and Internet Explorer supports Microsoft COM (Component Object Model) objects, including DAO (Data Access Objects) and RDO (Remote Data Objects). Instructions for using COM objects with Java are included in Visual J++ and on Microsoft's website. Microsoft has included a JDBC interface to ADO in their SDK for Java 2.0 (currently in alpha).
Other alternative database connectivity solutions can be found at the Gamelan website.
Finally, you can write your application in such a way that would not require database connectivity on your clients. Typically, this involves a 3-Tiered model with client applications or applets connecting to a server which handles most of the program logic. The server in turn connects to the database, either using JDBC or some other connectivity solution.
JavaSoft has broken categorized JDBC drivers into four basic groups. They are:
- JDBC-ODBC Bridge Driver:
The JDBC-ODBC Bridge driver translates JDBC calls into ODBC calls on the client machine. This involves native method calls. Presumably, the Microsoft ADO JDBC driver would also fall into this category as it also maps JDBC to another database API used to access a broad variety of databases.- Native-API Partly-Java Driver:
This type of driver translates JDBC calls to their native database API on the client machine using the vendor's native API. They, like the Bridge, require native method calls.- Net Protocol All-Java Driver:
This type of driver uses an all-Java driver, deployed on the client, to speak to a server, which translates the calls into native API database calls. This category requires some intermediary service (typically called middleware).- Native Protocol All-Java
This type of drive speaks directly to the database server using the database server's native network protocol.Click here to see a comparison of different JDBC Driver types and their capabilities.
For more information, visit JavaSoft's JDBC Driver Page.
I am in the process of compiling a list of available drivers and detailed descriptions of how they work.
JavaSoft has list of most JDBC drivers at their website.
Middleware servers open up a wide range of databases to JDBC without requiring customized software installation on client machines. Because the middleware JDBC drivers themselves are Pure Java, they can be distributed at runtime as part of an applet or application.
Middleware servers can also serve data from database engines that normally have no server. Many desktop databases, including Microsoft Access, Paradox, and dBASE do not include a database server, only an engine for reading local databases. A middleware server can act as a server for these types of databases.
Middleware servers can translate calls to access a server that would normally not be accessible to Java. For example, a middleware server could translate requests between a JDBC applet which speaks TCP/IP to packets for a server that only spoke IPX.
Many middleware servers can open paths to a number of different databases of different types simultaneously. If your data is stored in a variety of different databases, thi may eliminate the need for multiple drivers in your client applications.
Middleware servers can add a layer of security, requiring additional authentication and validation of client requests. Furthermore, they help mediate the requests from the client connections, which could reduce server load and (since all requests to the database server itself come from a single middleware server) avoid connection limitations, license restrictions, and can reduce costs.
Middleware server may also aid in building scalable servers by distributing client load over several database servers. Furthermore, it may reduce updates to the client applications (or applets) to accomodate a changes in the database server.
As with any system, the more layers that you introduce, the more complicated management and development becomes. In addition to client software and a database server, you have to worry about the state of the middleware server. Debugging may be difficult if you are not sure if a bug is in the client, the driver, the middleware, or the database server.
There may be hidden costs to consider when buying a middleware server, notably the hardware and administration time and energy it may require.
Finally, middleware servers can increase your network traffic, decrease performance, and affect the scalability of your client-server application because all requests need to be processed by the middleware server before being forwarded to your database server.
To speed up development and deployment of JDBC-compatible applications, JavaSoft and Intersolv created a JDBC-ODBC bridge which translates JDBC calls into ODBC. ODBC is Microsoft's Open Database Connectivity standard which has been widely accepted for Windows-based databases database clients. ODBC is also available on the Mac and some UNIX platforms, though the Bridge is so far only available for Win32 and Solaris. With the Bridge, Java developers can begin applications development with the hundreds of pre-existing ODBC drivers.
The JDBC-ODBC Bridge depends on the cooperation of several different components, many from different vendors, to get data from your database to your Java code. These components include:
Some ODBC drivers may require their own set of dependant components to span different network protocols or APIs.
- The JDBC Driver Manager (from JavaSoft)
- The JDBC-ODBC Bridge Driver (from JavaSoft and InterSolv)
- The ODBC Driver Manager (from Microsoft)
- The ODBC Driver (hopefully from your database vendor, though possibly from a third party)
- The Database (from your database vendor)
Each of these layers requires translating your request for data into a new, and possibly very different, format. Similarly, the response returned from the database needs to be translated several times before it reaches your Java code. Each translation introduces its own set of limitations and possibly bugs, in addition to consuming memory and computing power.
The JDBC-ODBC bridge is only as strong as the weakest of the links in the chain that support it. The number of layers also make the JDBC-ODBC bridge the worst of possible performers with respect to speed and memory usage.
From JavaSoft's website. It is also included as part of the JDK 1.1 release.
There are versions for both Solaris and Windows 95/NT.
The JDBC-ODBC bridge is included with JDK 1.1.x. For it to operate correctly, you must have your paths set up correctly and have ODBC installed on your machine.
ODBC configuration depends on your operating system and ODBC version. I have some instructions available here.
You will need a native code library for Netscape. I believe these can be acquired from Intersolv, but I have no further information.
JavaSoft is making JDBC part of the core API for JDK 1.1. Most Java tool vendors have not only agreed to support JDBC, they are bound by their licensing contract to support it within a reasonable amount of time after the final release of JDK 1.1. While at least one tool vendor (Microsoft) has argued that they reserve the right to choose which class libraries they distribute with their product, they will almost certainly support JDBC.
The JDBC core is written entirely in Java and thus should work in most current IDEs in its present state. JavaSoft has provided source code for the JDBC API to assist JDBC driver developers and programmers.
Microsoft provides support for JDK 1.1 in the MS SDK for Java 2.0 (currently in alpha). Symantec has released preview versions of JDK 1.1 support for Cafe. Both of these environments support JDBC.
The JDBC driver manager, which is written entirely in Java, handles loading and unloading drivers and interfacing requests with the appropriate driver. It was JavaSoft's intention to make the use of a specific JDBC driver as transparent as possible to the programmer and user.
Any driver fully meeting the JDBC specification should work with any IDE that is capable of supporting JDBC. On the other hand, most driver developers do not release the source code for their drivers, so you will be unable to debug the actual driver itself. Furthermore, even with source, a driver which requires a native code interface will require an IDE capable of debugging native code, if that is what you need.
Apart from limitations with specific JDBC drivers, changing from one JDBC driver to another requires only a few changes to your source code or configuration file.
Symantec Cafe supports JDBC programming with their most current version (1.51). Instructions for installation and use are available on Symantec's Website and FTP site. Please contact Symantec for more information. Symantec also has a preview version of Cafe (1.53) which supports the complete JDK 1.1.
Visual Cafe should support JDBC without any problems.
Symantec has a new product, Visual Cafe Pro which includes a workgroup version of their JDBC-compatible middleware server, dbANYWHERE. Visual Cafe Pro also includes a number of database controls intended for use with dbANYWHERE. To my understanding, while dbANYWHERE is JDBC compatible, the Visual Cafe Pro environment and controls are based on dbANYWHERE-specific functionality. While you will be able to program with another vendor's JDBC driver, you may not necessarily have access to the full range of the IDE's database capabilities without dbANYWHERE.
Microsoft's Visual J++ should be able to work fine with JDBC as long as the programmer keeps one very important thing in mind: Microsoft does not currently support the native code interface promoted by JavaSoft in their Java VM JVIEW.EXE. This of course means that any JDBC driver that uses JavaSoft's native code interface (for example, the JDBC-ODBC bridge driver) will not work with Microsoft's JVIEW.EXE or with Internet Explorer.
Microsoft includes a tool to add source files to the Visual J++ environment for debugging purposes, JAVASRC.EXE. It can be found in the Java/Classes subdirectory of your main Windows directory.
Microsoft includes some support for JDK 1.1 in the MS SDK for Java 2.0. This includes JDBC, but does not yet include native code interface support.
When programming applets with JDBC, it is important to remember:
- The applet security model prevents untrusted applets from making network connections to any host except the originating host. This means that an untrusted applet using JDBC can only connect to a database server (or middleware server) running on the same host that the applet was downloaded from.
- The applet security model prevents an untrusted applet from accessing local system resources, including ODBC configuration information. Even with the correct native code libraries pre-installed on the local machine, the JDBC-ODBC bridge requires access to correctly-configured ODBC data source information stored on the local machine. Some drivers (including many ODBC drivers) may require that the database be installed on a local drive or a mounted network resource, both of which are inaccessible to Java applets.
- The applet security model prevents loading untrusted native code over the network. Specifically this means that drivers which require native code libraries, like the JDBC-ODBC Bridge, cannot be loaded into a browser from a web server. The native code libraries need to be installed on the local machine before starting the browser.
- Not all Java VMs use the same native code interface. Notably, Netscape and Microsoft do not use the same native code extensions as Sun and JavaSoft. JavaSoft is planning to make their native code interface part of the JDK 1.1 specification, so you will only need to make sure people have the correct native code library for a particular operating system. Until the interface is implemented in all VMs, though, drivers which require native code (including the JDBC-ODBC bridge) need native code libraries specific to the particular Java VM.
- Some applet security models prohibit loading packages under the java.* tree. This prohibits loading the java.sql.* package, required by both the applet and driver, over a network. Either the java.sql.* package would need to be installed locally before starting the Java VM or browser, or both the applet and driver need to be compiled to load the JDBC API classes from a different package name. Symantec's dbANYWHERE, for example, uses symjava.sql.*. Other drivers use jdbc.*. This problem should be resolved when Java VM and Browser developers incorporate the new JDK 1.1 specifications (which will include JDBC).
In general, for applet JDBC development, you should plan on using a Net Protocol All-Java Driver (category three) or a "Pure Java," Native Protocol All-Java Driver (category four). Furthermore, until JDBC is integrated into browsers and VMs, you will need to develop your applets using an alternative package name for the JDBC library. That alternative package name will need to match the name supplied by your driver vendor.
If you have followed all of the restrictions above to program your applet and it still does not work, before posting your question to a newsgroup (preferably comp.lang.java.api), be sure you check your applet works in the JDK appletviewer. appletviewer does not have any of the security restrictions listed above when loading local applets. Also, try to get a stack trace of any exception it may throw.
- JDBC
- Java DataBase Connectivity. An API for database development in Java developed by JavaSoft and Intersolv.
- ODBC
- Open Database Connectivity. An API dor database development developed by Microsoft for Microsoft Windows. It has since been ported to Windows NT, Windows 95, Macintosh, ans some UN*X systems.
- SQL
- Structured Query Language. A language used by database engines and servers for data acquisition and definition.
This FAQ is maintained by Thornton Prime of YoYo Publications. There are no guarantee of accuracy or usefulness of this FAQ, nor shall either Thornton Prime or YoYo Publications be held liable for use or misuse of the information contained herewithin, blah blah blah.
This FAQ is constantly under development. If you have suggestions, submissions, or corrections, please submit them to thor1@themall.net. I will be happy to give you credit here.
I would like to include more information on available JDBC drivers and development tools. Commercial vendors are invited to send information to the address above.