John Reynolds's Blog

Community: JavaDesktop Archives

Why Use A Database Instead Of ____?

A recent blog entry by Simon Morris questions the usefulness of including a relational database (JavaDB) with the Standard Edition of the Java Development Kit (SE JDK). The JDK is primarily intended for the development of Desktop applications, and in Simon's words:

"most real desktop applications (browsers, players, word processors, video editors) are not database heavy, why is Java DB being included in the SE JDK?"

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"

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.

Continue Reading...

JSF and AJAX versus Swing

Evan Summers wrote a very good blog on "Swing versus everything else" a few days ago, and it started me thinking...

Many heated battles have been fought in the war between browser-based applications and "stand-alone" applications... and when a new skirmish flares up it often brings to mind lyrics written by (Country) Joe MacDonald back in the 60's:

"And it's one, two, three,
What are we fighting for?
Don't ask me, I don't give a damn,
Next stop is Vietnam;
And it's five, six, seven,
Open up the pearly gates,
Well there ain't no time to wonder why,
Whoopee! we're all gonna die."

The roots of this User Interface war go deep to an era long before Java existed... the war is really about the best way to implement the client aspects of client-server computing: Dumb-terminal versus Smart-terminal.

I've said it before, and I will say it again, a computer that is not regularly connected to the Internet is not of much use to most people. To quote Sun's motto: "The Network is the Computer"... and that makes the device that you sit in front of a glorified terminal.

At this point in time, I believe that the substance of the battle between JSF and Swing is mostly over the amount of functionality that an application possesses when it is not connected to The Network:

• JSF applications are powerless when The Network is absent
• Swing applications can operate on local data when The Network is absent
  

My belief that The Network is at the root of the war was reinforced on Wendesday when I got a sneak peak at Oracle's ADF Rich Internet Components at the Oracle Developer Day held here in Austin. The newest components are snazzy-looking, AJAX enabled, and with Tools like JDeveloper it is very easy to create non-trivial applications with them.

From a presentation on NetBeans and Matisse presented by Greg Sporar at Austin's JUG a few months ago, I also know that it's pretty easy to create non-trivial applications using Swing components.

If you will grant me the latitude of gross generalization, the biggest difference (from an architect's perspective) between a Swing application and a JSF application lies in where the bulk of the application logic is executed... on the client (Swing) or on the server (JSF).

No doubt we should quibble about the phrase "the bulk of the application logic"... It's quite possible to build a very "thin" Swing front-end on top of Web Services, and with more and more client side Javascript the AJAX components can seem to be pretty "thick". Add to this equation the use of Derby-in-a-browser to provide offline capabilities and I am not left with much of a distinction between Swing and JSF clients.

So what are we fighting for?

I think it is easier to say what we are fighting against... We are fighting against having to use wildly different programming styles in a single application. I say "We", because I think this is the goal of both the JSF and the Swing camps.

Swing advocates obviously like the ability to do everything in Java and they hate markup (except for Josh Marinacci and Ethan Nicholas).

JSF advocates are much more markup-tolerant, but they want to hide all the the markup ugliness (and Javascript) within nicely wrapped packages.

If you can get past these differences, then you will find that the client-side JSF event-handling-logic is not all that different than Swing's event handling logic.

So is either side ever going to "win"? I dearly hope that they both do... and I pray that both sides don't destroy each other or:

"Whoopee! we're all gonna die."

This work is licensed under a Creative Commons License.