JavaDB: An idea whose time has finally come?

Last year, at ApacheCon, according to Sun Chief Open Source Officer Simon Phipps, Sun senior staff engineer Francois Orsini apparently gave a demonstration of JavaDB -- Sun's version of Apache Derby.  Apache Derby is basically a full blown relational database management system (RDBMS) that's based on pure Java.  In other words, all it needs to run is a Java Virtual Machine.  Derby became a part of the Apache Project when IBM open sourced it in 2004.  I can easily imagine JavaDB serving as a repository for office productivity documents. The technology was original called Cloudscape and originally came to IBM by way of its acquisition of RDBMS solution provider Informix which in turn had at one point acquired a company named Cloudscape (formed as a startup by some ex-Sybase people).  IBM continues to have a version of Derby under the Cloudscape brand name.  Meanwhile, Sun's Tim Bray announced at ApacheCon that JavaDB (Sun's version of Derby) will be included in Sun's Solaris Enterprise System.

The news escaped my interest until just after a Sun roundtable that I attended concluded and Phipps, who originally blogged about JavaDB, asked me if I paid any attention to what he'd written. I had not. But, based on the look in is eyes, my spider senses told me that I probably should have.  It's taken me a while to give JavaDB a look.  But, now that I have, I'm glad I did.  I'm not sure that Orsini's aforelinked blog does JavaDB (and Derby) justice for what it is and what it's capable of.  But if I didn't know better, I'd say it could be a missing link if not the missing link in solving the number one objection to thin client computing: being able to  work offline. It could also address another problem for companies going down the handheld route; because it's based purely on Java and because there's a Java Runtime Environment for most handhelds (as well as notebooks and desktops), JavaDB offers an opportunity to standardize on one database technology across many devices (BlackBerries, Treos, Windows Mobile-based devices, etc.). 

Back to being able to work offline, for as  long as I can remember, every time I've written about the death of the fat client at the hands of the sheer elegance of thin client computing (where everything the apps, the storage, etc. is in the cloud), I've been hammered by the offline crowd.  "What happens when you're not connected to net?" They ask.  "That's why fat clients rule.  Always will."  Even my fellow ZDNet blogger George Ou refuses to throw me a bone -- taking on the role as fat-client whip every time he encounters my thin client rhetoric. 

Having inched Web-based applications several notches closer to the sort of interactivity and richness that fat client software (the software that runs on top of operating systems like Windows, OS X, and Linux) is known for, AJAX style programming has probably done more to revive the idea of thin client computing than any other recent technology fad.  But, for Web-based applications, it still doesn't solve the problem of what to do (beyond having a fat client at the ready) when there's no connection.  Using blogging as the perfect broad-based example, a lot of bloggers update their Weblogs by using the browser-based Web forms that are associated with their blogging service. With no Web server to get its Web pages, forms, and instructions from, how is a disconnected thin client supposed to work?  Because of the way JavaDB basically persists in a browser's cache without an online connection (the same way a Web page might be retrievable from browser's cache even though there's no connection), JavaDB solves a major league storage problem when it comes to working offline with structured data. 

Shortly after Orsini gave his demo, I tracked him down for some more details on the problems that JavaDB solves.  Orsini gave me the tops of the waves first; stuff that interests developers and admins like how JavaDB is SQL 92 and 2003 compliant and the database.  One of JavaDB's key features according to Orsini, is its light footprint. Java isn't exactly known for being a svelte consumer of system resources.  Throw a full-fledged database on top of that and you could see how enterprise developers might start to shy away.  But Orsini swears it's lightweight and fast and apparently showed as much at ApacheCon when the demo he did in Firefox used a small plug-in that ran on top of the Java Virtual Machine plug-in for Firefox.  That along with the fact that the brute force of Moore's Law is finally having a bit more of an impact on handhelds (with memory costs dropping and processors getting more powerful and less power consuming) could mean that JavaDB, a technology which is based on nearly 10 year old database technology, may have finally reached a tipping point. 

Of even more interest to those deploying mobile databases is how, like dyamically loaded Java apps themselves, JavaDB is easy to deploy over the air from a Web page.  There's just one Java Archival Resource (JAR) file: the file that contains all the Java classes that are necessary to get JavaDB up and running.  In his demo at ApacheCon,  Orsini showed tax filing application.  He showed how an app would automatically download as part of an HTML application, how the egine will resides securely in the local cache, and then how it all works seemlessly offline. 

This doesn't have to be about just rows and tuples of databases either (although many enterprise developers may want it for just that).  I can easily imagine JavaDB serving as a repository for office productivity documents (Microsoft Office, OpenOffice or any one of the new breed of AJAX driven offerings for which JavaDB could be perfect).  All that would be needed is some sort of software shim that makes the JavaDB look like a filesystem.  Never heard of database driven filesystems? Database technology is in fact what will run Microsoft's future file systems.

Once I realized what JavaDB was capable of, my mind start to whir a bit on the possibilities.  For example, let's say all PCs, public kiosks, and seat-back Internet terminals on the planes we fly include at bare minimum a browser, Java, support for Java Specification Request 80 (more on that in a second) and a USB port.  Now imagine that everything you normally keep on your PC (documents, contacts, etc.) is stored on a USB key that's compliant with both JavaDB and JSR 80: the Java USB API that, according to official description, "allows Java applications to discover, read, write, and manage USB devices." 

Once the browser is started, by virtue of its Java JSR 80 support, it should be able to -- within the context of the Java plug-in -- see a list of HTML pages on the USB key.  Going back to the earlier example of blogging, one of those pages might be named "Create a New Blog."  By clicking on that, a Web page is launched that presents the blog authoring form and then, in true offline fashion,  when the SAVE button is pressed (after you've written something), it calls in the JavaDB plug-in, loads the database, stores the data (replicates it from the JavaDB in cache to the one on the USB key), and gives control back to the end user for some other task.  Or, provided the receiving end were set up for it, some AJAX code can check to see if the online repository for the same data is available and just send it there.  But, when it's not,  the next time the Internet is available "to the USB key," the data in the JavaDB is replicated to the appropriate database in the cloud.  With the right scripts, JavaDB could easily multiplex to a variety of other non-native data stores (eg: TypePad for a blog, a SQL database for the enterprise, and your local contact manager).

Today, working offline is the major objection to working with AJAX-driven Web-based productivity apps.  Not so much so with real database apps because enterprise IT departments have learned to pick a strong mobile database offering like Sybase's SQL Anywhere that's preconfigured to synchronize with a mother database.  But virtually all of those offerings-- be they from Sybase, Oracle, IBM, or Microsoft-- require fairly thick and non-dynamic (in terms of the way code is loaded) clients.  Some offerings like those from Microsoft tie you to Microsoft's operating systems and, as a result, they've had to force certain client technologies on their end users.  What if you're on a platform from Palm or RIM or you're running Linux on some desktops? 

Furthermore, software developers have no motivation to turn those database technologies into file systems for storing productivity documents since, because of their limitations, they'll never be ubiquitously supported and the ROI of adding such a feature would be quite questionable. But, given it's dynamic nature,  the ubiquity of browsers,  and it's OS-agnosticism (by virtue of using a JVM), JavaDB could turn into that technology if only a few key developers prototyped the possibilities.