| Contents | Prev | Next | JDBCTM Guide: Getting Started |
Many Java application developers would like to write code that is independent of the particular DBMS or database connectivity mechanism being used, and we believe that a DBMS-independent interface is also the fastest way to implement access to the wide variety of DBMSs. So, we decided it would be useful to the Java community to define a generic SQL database access framework which provides a uniform interface on top of a variety of different database connectivity modules. This allows programmers to write to a single database interface, enables DBMS-independent Java application development tools and products, and allows database connectivity vendors to provide a variety of different connectivity solutions.
Our immediate priority has been to define a common low-level API that supports basic SQL functionality. We call this API JDBC. This API in turn allows the development of higher-level database access tools and APIs.
Fortunately we didn't need to design a SQL API from scratch. We based our work on the X/Open SQL CLI (Call Level Interface) which is also the basis for Microsoft's ODBC interface. Our main task has been defining a natural Java interface to the basic abstractions and concepts defined in the X/Open CLI.
It is important that the JDBC API be accepted by database vendors, connectivity vendors, ISVs, and application writers. We believe that basing our work on the ODBC abstractions is likely to make this acceptance easier, and technically ODBC seems a good basis for our design.
ODBC is not appropriate for direct use from Java, since it is a C interface; calls from Java to native C code have a number of drawbacks in the security, implementation, robustness, and automatic portability of applications. Thus, we have constructed an API that can easily be implemented on top of ODBC short-term, and that can be implemented in other ways longer term.
We are grateful to all the reviewers who took the time to read and comment on the various drafts, but we would particularly like to thank Azad Bolour, Paul Cotton, Ed Garon, John Goodson, Mark Hapner, Tommy Hawkins, Karl Moss, and Barbara Walters for providing sustained review and helpful feedback over many drafts and revisions of the API.
The errors and omissions that remain, are however, all our own work.