Database Development in Java

As you've most likely already heard, one of the features in JDK 1.1 that Sun is most proud of is something it's calling JDBC. Although (probably as a testament to the quality of their legal department) Sun is insisting that JDBC is an actual, trademarked name and not an acronym, it's not hard to make the leap from another, already widely used acronym in the database world (ODBC--for Open DataBase Connectivity) to know that Sun is talking about something called Java DataBase Connectivity.

If it sounds simple, that's because it is. Although many recent computer professionals have looked down on their cousins in the world of database management, the fact is that because such a significant percentage of the world's computing resources are devoted to databases there is an entire, and often very separate, field devoted to them.

Often today in U.S. universities, people earn qualifications for database design and management that are quite separate from those of their regular computer or information science counterparts. The database is a phenomenon in modern computing, and one that JavaSoft could scarcely afford not to pay heed to--especially considering the preponderance of database-related applications cropping up in the Internet venue.

Also important is the fact that the other acronym we mentioned (ODBC) is a product of Microsoft--and a careful reader can almost sense the competitive tension while reading the JDBC documentation. Database interfaces are big business, and if some other company managed to shut Sun's Java products out of the serious database applications world, it could be considered a major problem for them.

So what exactly do we get? There's now a java.sql package in the API. For the database illiterate, SQL (for Structured Query Language) is something akin to a standard language for communicating with modern database software. One could almost call it a programming language, but there are notable differences that naturally follow from the very different (and highly specific) role it plays in handling the operation of databases.

SELECT * FROM MYTABLE

The line above, one of the simplest lines of SQL you could write, simply calls for a database to return the entire contents of the table "MYTABLE" as a result, with a table being, very simply, just a collection of "rows" of data, each of which containing information specified in the table's "columns."

The bottom line is that we've now got a built-in system for passing commands to a database in SQL and looking (with relative ease) through the results we get back.

Maybe you're asking why this should be treated as though it's so complicated? All we're doing is passing a string of SQL commands to database program, and then receiving a string of the search results in return, right?

Not really. For starters, of all the half-dozen fairly popular database programs available today, there is shockingly little standardization. Each may have different conventions for how it receives queries (especially via the network, which is how you'd be most likely to do it), how it formats and arranges results, how it communicates errors, and even how closely it sticks to the SQL standard. As evinced by the ODBC, you typically need driver software to access them. Of course, ever the sly ones, Javasoft created something called the JDBC-ODBC Bridge, which basically allows the API to co-opt existing ODBC functionality on client machines--with special respect to the existing database drivers. More generally, support for the JDBC appears to be evolving fairly rapidly so that this rather sneaky measure won't be necessary for long, and the API will contain drivers of its own for the more popular products.

Using the JDBC is functionally straightforward, albeit low level. You create a Connection object (for connecting to an actual database), which you can use to create a Statement object (for transmitting your SQL statement of choice), which in turn will return a ResultSet object containing an enumeration of the results.

Nothing fancy about this--you're still writing SQL and reading your results back almost directly from the table, but the drivers, networking, and all the rest are taken care of for you, and, in most cases, you no longer have to worry about what particular kind of database you're working with.

It ends up being a clever little extension of one of Java's original points: Now, even use of databases is platform-independent. Sun tells us that future plans include using the basic features in the JDBC to make much more user-friendly, high-level database interfaces. One can imagine objects that represent the table rows, having fields that correspond to the columns. All in all, we like it.

We urge the reader to read up on databases in general and JDBC more specifically, as demand for knowledge of both is only likely to increase. Join us next week for still more dirt on developing in Java.

Past installments of Java Jolt