Eat your own dogfood part 3: JDBC4Me

I've done it. After almost ten years of fruitless hacking at ambitious architectures that didn't really do anything, I have finally uploaded a first version of a working piece of open source software: JDBC4Me. I won't expound on how it will radically alter our conception of data or how it wil effect a dramatic paradigm shift in database access. It won't.

It's nothing earth-shattering. For the non-programmers: it helps you retrieve, insert and update data from a program from and into a database in a more user-friendly way. It does nothing new, but it does it in a way I found lacking in other tools. If you're not a Java programmer who's reasonably well-versed in JDBC you probably have no use for it whatsoever. That's perfectly fine.

One of the biggest pitfalls in building software is trying to be all things to all people. The choice of what to leave it out is often harder than what to put in.
JDBC4Me does one thing, and I think does it reasonably well for a sub 1.0 release. It has documentation and lots of unit tests. While writing these tests I discovered and fixed scores of obvious and some pretty nasty bugs. I deliberately tested against only three database products and their most common Java drivers: Oracle10, MySQL5 and Derby10. Use anything else, and the tool will default to settings that may or may not work. I'm quite happy to include Microsoft SQL server and PostGreSQL, but only when I have time to test them properly. If there's one thing I discovered in working with databases in Java, it's that vendor-neutrality in generic tools is overrated. Hibernate and other ORM tools are keen to lure you into this trap and pretend that changing vendors is as simple as updating a configuration file, but the soldiers in the trenches know better.

Here's another thing I learned. The more you zoom in on a programming challenge, the hairier it gets. You start off thinking that all driver vendors conform neatly to the JDBC standard, especially a multi-billion dollar empire like Oracle. Yeah, right. I actually discovered that Oracle had the worst standard compliance of all, and I was unlucky enough to base the first version of my code on Derby, which had the best compliance (not surprising, as Derby is written in Java). I made assumptions that the driver could provide certain metadata, which it didn't in Oracle, so my well-intentioned vendor-neutral code quickly had to go and I found myself writing an Oracle10Proxy, a Derby10Proxy and a Mysql5Proxy. It hurts my eye, it flies in the face of everything JDBC stands for, but it's the only way to make sure that each database performs as it is supposed to perform.

Having lots of features to please lots of users counts for nothing if the features you need are poorly implemented. A housing site that covers 20% of all properties in a country is less useful than one that has 80% in a single town, if that happens to be the town I want to live in.

Next time I'll share an experience of using other people's open source software. I'll try to be friendly and forgiving, BUT IT KEPT CRASHING ON ME.
"Yeah, but it has many more features than [...]"
- BUT IT KEEPS CRASHING!!
"You can write your own macros..."
- BUT IT KEEPS CRASHING!!
"It's free"
- BUT IT KEEPS CRASHING!!