JDBC

The second release of the Java platform ushered in the first major support for database persistence with the Java Database Connectivity specification, better known as JDBC. Offering a simple and portable abstraction of the proprietary client programming interfaces offered by database vendors, JDBC allows Java programs to fully interact with the database.

This interaction is heavily reliant on SQL, offering developers the chance to write queries and manipulation statements in the language of the database, but executed and processed using a simple Java programming model.

The irony of JDBC is that while the programming interfaces are portable, the SQL language is not. Despite many attempts to standardize the SQL language, it is still rare to write SQL of any complexity that will run unchanged on any two major database platforms. Even where the languages are the same, each database performs differently depending on the structure of the query, necessitating vendor-specific tuning in most cases.

There is also the issue of tight coupling between Java source and SQL text. Developers are constantly tempted by the lure of ready-to-run SQL queries either dynamically constructed at runtime or simply stored in variables or fields. This is a very effective programming model until the minute you realize that the application has to support a new database vendor and that it doesn’t support the dialect of SQL you have been using.

Even with SQL text relegated to property files or other application metadata, there comes a point in working with JDBC where it not only feels wrong, but also becomes a cumbersome exercise to take tabular row and column data and continuously have to convert it back and forth into objects. The application has an object model—why does it have to be so hard to use with the database?