A Good Day for Hobbyists and Corporate Developers Alike

Derby Hat

Microsoft recognized long ago that the way to a programmer’s heart is to simplify the heck out of their development efforts. VB6, the empowering champion of corporate developers the world over, was the pinnacle of MS’ achievement in this regard. Some of this ease of development could be put down to the Jet database that shipped with VB.

Bundling a small, simple desktop database that you could rely on to simply “be there” was a master stroke by MS, because it meant that corporate (and hobbyist, for that matter) developers could try things out quickly, get things working at a prototype level, before shifting development over to a more production-worthy enterprise DB – at which point, typically, development would slow to a crawl. Many projects got off the ground in this way, and might not have seen the light of day if their barrier to entry had been higher.

So, to Sun’s announcement that they’re going to bundle a snapshot of the open-source Derby database with the JDK. The version that they ship will be branded as “Java DB” – giving us something of a clue as to why Sun is making this move. They obviously want to continue to simplify development, to lure in more corporate and hobbyist developers. Providing a single “obvious” option is a surefire way of simplifying things.

Derby is small and neat (2MB), yet is Java EE-compliant and supports transactions, concurrent users, triggers, Java stored procedures (yummy) and encryptable databases.

Sun is taking the correct (albeit brave) course with this move – despite cries of horror from interested observers.

There are two valid complaints that have been wailed in Sun’s direction: first, that this will alienate developers of other “little” database engines such as HSQL. It’s a fair point, but what are these disgruntled vendors going to do, run into Sun’s HQ with a sawn-off shotgun? It’s more likely that they’ll grumble for a little while, and then knuckle down and focus on making their own database products even better, i.e. to compete on old-fashioned things like features, ease of use and robustness.

The second complaint is that this move will create a fork in Derby: that developers will use the bundled version by default simply because it’s there, even when shinier, newer versions are just a quick download away, complete with critical bug-fixes and so forth. Again this is a valid point, but we might just have to live with it, if the result is that Java attracts a new wave of corporate developers, still looking for a home after VB6 curled up its non-OO toes.

Sure, Derby will continue to be developed and the version shipped with the JDK will lack the newer features. But new features aren’t everything. Java developers will now be able to rely on there being a commonly available database; the same version everywhere, that they can target with confidence. Java DB will be the default option as it’ll just “be there” (just like Jet), and be easily good enough for small projects and rapid prototyping.

So, there are cries of alarm at this move, but – despite the obvious drawbacks – bundling a reference database with the JDK is just the right thing for Sun to do. (On the other hand, bundling more and more fluff into the increasingly bloated JRE is a different matter entirely; and Sun should think about taking a serious step back from this alarming policy).

About the Author

Matt Stephens is a senior architect, programmer and project leader based in Central London. He co-wrote Agile Development with ICONIX Process, Extreme Programming Refactored, and Use Case Driven Object Modeling with UML - Theory and Practice.