"most real desktop applications (browsers, players, word processors, video editors) are not database heavy, why is Java DB being included in the SE JDK?"Simon's a smart guy (I sincerely believe that)... But I think that he's missing the nature of most of the software that is written for businesses. Most business applications are concerned with data entry, data manipulation, and data presentation... And in most case that data has value far beyond the scope of a single application.
Let's take look at word processors: A very common business function for a word processor is to create a "form letter" and populate fields of the letter with data that comes from another source (sometimes a database, sometimes a flat file of some sort). Of course the word processor's author could come up with a custom mechanism for extracting data fields from a file... But if an RDBMS (Relational Database Management System) is used, much less custom code is required, and (much more importantly) the data will be stored in a format that makes it available to other applications.
Okay... So maybe you agree with me that storing data in a format that is accessible to many applications is a good idea, but why not use XML (eXtensible Markup Language) files instead of an RDBMS. XML files are very easy to parse, and they are very easy to extend over time.
True... But what if multiple applications need to be creating, updating and deleting data simultaneously?
All "real" Database Management Systems are designed from the ground up to handle simultaneous inserts, updates, and deletions. Options abound for managing simultaneous access to tables and records, and for handling collisions and potential deadlocks. Many people have worked for many years to fine tune these systems, and they work very, very well.
Okay... So maybe you are beginning to agree that an RDBMS is a good idea for inclusion in any development kit... but why JavaDB? It's not a "real" RDBMS. It's just a toy, and there are many, many alternatives.
Now we have reached an agreement of sorts. I don't really understand the merits of JavaDB over HSQLDB or any other contender... but I also have to admit that I really don't care all that much.
What is important to me is that an RDBMS is included (by default) in the development kit. Inclusion of something like JavaDB means that every single Java tutorial can assume the presence of an RDBMS. Every new programmer learning Java can painlessly learn to program using JDBC (Java Database Connectivity) and learn enough about SQL to keep them from being dangerous.
But wait... Isn't Java Object Oriented? Shouldn't Java developers be focused on using persistent objects rather than fields from a database?
I know that it's contrary to promote tables and fields over persistent objects, but in defense of this position I'd like to share with you some insights that Ken Orr (of Warnier-Orr diagram fame) shared with me (highly paraphrased below)...
"An object is just a single hierarchical view of the underlying data. With an RDBMS, you can support many views of the data... each of which is appropriate for the application that needs it. Constraining data to a single view (as an object) is robbing the data of some of its worth"If you have ever written an application and had to implement the "Fast Lane Reader Pattern", then you have had a small taste of what Ken is talking about. Often, you do not need to retrieve all of the fields of an object... in fact the performance of your application can be severely hampered by doing so.
Data is often a company's true "treasure"... They slice it, they dice it, they analyze it right, left, up, and down. Reports are written against this data. Presentations are built from this data. Businesses literally live or die on their ability to leverage this data.
This is true whether you are writing a Browser-based application for a business, or whether you are writing a Desktop application for a business. Data is really important, and an RDBMS is a really good tool for handling data.
(Cross-posted at my java.net blog)