Java and Databases - the Great DisasterThere is a great tragedy in the world of Java that rarely gets discussed. All around us, every day, the horror continues, yet we pretend it's not there, even as we stand in the shadow of the towering monsters it begets. The horror mocks and humiliates java programmers across the world, constantly pulling the rug out from java and it's Great Promise: to rid the world of the evil's of C. We won some battles - no more header files! no more malloc()! - but for some of us it seems we may have lost the war. I'm talking about JDBC.
What is C?
C was not some rosy nirvana of a programming language, devised over the course of 20 years by the brightest and best theoreticians and experts around the globe. It was a small language put together quickly to solve a certain domain of problems. In short, in many many ways, it sucked. It sucked even more so when people started using it as a Universal Hammer ("when all you have is a hammer, all the problems in the world start looking like nails...") and it was exposed to vast swathes of usage that it was never designed with in mind.
C++, and later Java and C#, in correcting a vast number of those problems (and, let us not forget, borrowing/stealing a lot of good ideas from other people's attempts to fix C - Modula for instance), sparked a legion of religious wars, from "Object Oriented Programming is too slow for the real world!" to "Garbage Collection is a waste of time!"... you've seen these arguments around (they don't die easily). C++ initially spearheaded the OOP revolution (now cut and dried), and Java/C# started the managed-memory/VM revolution (not entirely finished, but now comfortably in a position of world domination). Let us not forget C had neither.
C didn't even have the concept of namespaces. For non-C coders, imagine what life would be like if you couldn't put your classes into packages. If every time you wanted to make a new class, you had to think of a name for it that *no one else in the world had ever used for their class*. Nightmare? You bet.
What is JDBC?
Well, in a nutshell, it's "ODBC...in java".
What is ODBC?
Open DataBase Connectivity - this is nothing more or less than a strictly defined interface between applications and databases, that enables you to switch your database without having to rewrite your application. It came about in 1992, at the end of the eighties, where a lot of people had lost an awful lot of money from being tied-in to a single DB vendor and yet being unable to switch to a cheaper/better one (because they couldn't afford to rewrite all their application code from scratch to work with the different DB). Bear in mind this is also back in the days before OOP's world-domination, and long before the term "refactoring" had even been coined, so applications were generally much harder to switch to new systems.
Hmm. Hold up a minute there ... ODBC predates the OOP revolution. ODBC ... isn't OO. OOP has revolutionised development, *especially* when it comes to systems interfacing and data/code interactions and handling. i.e. ODBC doesn't use the most important invention ever made in it's own domain. In short, as far as 21st century application and systems development goes, ODBC sucks.
Java, the Giant-Killer
Java's core architects and early developers (Sun, IBM, BEA, etc) didn't shy away from turning conventional wisdom about VM's, GC, etc on its head. C# probably wouldn't have happened for many years to come had Java not got out there first and spent half a decade proving that, if you did it right, these concepts worked really really well in practical, real-world, programming.
Speak to developers who've spent a decade using Java professionally, and you'll generally find that improvements such as this are what have kept them with the language all this time - the oft-quoted (and oft-disparaged) claims that Java can reduce project total development time by typically 20%-30% compared to writing it in C++ are generally accepted and believed by these people, who've seen the same kind of time savings again and again. And it's fundamental improvements like this that provide those savings.
For instance, have a look at the Java 1.0/1.1 networking libraries. Compare them to C++ (don't even bother looking at C, it'll just depress you). Java was the first mainstream language to have "the internet" built-in to the core language. The standard libraries were full of things like the ImageObserver class, specifically designed to let you asynchronously download images over the net (back in the mid nineties when most people had very slow dialup access). There was an entire core library devoted to using the internet, and *it made the TCP and IP packets for you*. It actually arrived speaking HTTP out-of-the-box. (Of course, this was a major pain for all the people e.g. writing computer games, who actually *wanted* to be manually assembling their IP packets).
SQL, JDBC, and RDBMS
So, when it came to doing a library for possibly the most important thing in the computer world - accessing databases - what did Sun do? Did they rail against the status quo, and start with new technologies that would drag people into the new century, a fresh start that fixed all the problems of the last decade, and made DB development "easy", "quick", and "reliable"? Hell no! They ran away from the problem, and hid. They just pushed people towards a port of ODBC. A good port, yes, with lots of goodness of its own. But, fundamentally, ODBC again - with all the attendant problems of completely ignoring what OOP actually means, for instance.
Yes, JDBC is an API that uses classes, objects, etc. But ... have you actually looked at those objects? Some of them are barely even usable (which idiot thought it was a smart idea to make a new class that would represent a java Date as another class, *also called Date*, and would simply wrap the java Data class? Suddenly, all your code has to be full of fully-qualified class names because of a stupid, short-sighted decision).
Fundamentally, OOP programmers aren't interested in working in byte arrays: they want Objects. They don't want to write convoluted relationships in SQL: they want to use the nice, terse, clear language *they are actually writing in* to describe relationships.
Is there Hope?
Yes. It's called JDO - Java Data Objects. And Sun's been trying to kill it off, because the only thing Sun understands is J2EE, which means they CANNOT allow something as useful as JDO because their J2EE stack already duplicates and/or architects differently a lot of the fundamental concepts of "data", "code", and "development". This is all "in a good way", just so long as you are a J2EE developer. J2EE is great for the things its designed for. Sadly, for J2SE developers, J2EE can only handle a VERY small fraction of the programming tasks that java itself is excellent at.
So, Sun's not at all keen on "these JDO thingies" that seem to them to have no purpose. But they are quite possibly the ray of light that will be the salvation for Java programmers everywhere, the future of DB development. The two questions now are: will JDO survive the cull, and ... how good is it anyway - does it fulfil its promise?
More to follow...