In Defence of the Desktop
Recall the motto "when the only tool you have is a hammer, every problem looks like a nail". One wonders whether the reverse is true? If you spent all your time banging in nails, are you inclined to judge every tool by its suitability to act as a hammer?
Reading through some of the recent comments on blogs and forums of late I've begun to wonder if there isn't a sizeable section of the Java developer audience who have forgotten the true nature of desktop software? I read comments attacking Swing as being too complex, and suggesting perhaps it should be more like those APIs used to build web application interfaces. At the same time I see a database being included as a standard part of the development kit for SE, the version of Java supposedly aimed at the desktop.
Now I realise that from a developer point of view the SE version of Java is just a generic flavour — the 'standard edition' which we can then augment with ME or EE, etc. But from a JRE point of view the 'standard edition' is aimed squarely at desktop users — Joe Soap, sat at his PC or Mac, at home or in his office. If Java DB turns up in the SE JDK, pressure will immediately begin to build it into the equivalent JRE (which is already bloated.)A recent editor's blog asks if a lopsided enterprise-heavy Java community is having a detrimental effect on Java's desktop efforts? I'm inclined to consider that perhaps it is.
Immersed in the heady EE-centric world which has dominated Java over the last five years or so (where most developer 'bandwidth' is about web frameworks and CRUD related development) it's easy for the true nature of the desktop to be forgotten. For web app developers CRUD seems to play a large role in their life. I'm generalising here, naturally, but web apps are more often than not heavily query based, of both the SQL and HTTP variety (although Ajax may mask that fact from the end user.) Database create, read, update, and delete operations form the backbone of such applications, and many tools and APIs exist to smooth the process of implementing such code.
If databases are the core of almost all web apps, then the same must be true for traditional desktop applications, right? Certainly judging by blog/forum comments a lot of Java developers seem to think it must.
Web browsers, mail clients, word processors, paint software, video editing, virus checkers, media players, spreadsheets — the list of desktop applications is seemingly endless. As with all software these applications are data driven, but how many actually need to make use of an embedded relational database and CRUD functionality? When I wiggle a mouse over a link on a web page, do I really want the browser to be formulating dozens of SQL requests to update some embedded database of the DOM state? Just how good is a relational database at keeping up with real-time edits in a Word document? Can SQL provide the complex and intelligent pattern matching required to find a virus within a file with the same speed as a piece of dedicated virus hunting code?
It occurs to me we have two very different beasts here. Most web applications are like card games: everything revolves around a turn-based system, with a trivial number of interactions possible at any given stage in the play. Most desktop apps are like 'twitch' video games (Space Invaders, Pac-Man): the action flows and the monsters keep on coming even when the player is idle, with a highly complex set of interactions possible at any given stage of play (as the player interacts with the environment and the environment reacts to the player.)
The linear turn-based nature of web applications fits well with database centric work, indeed many web apps are nothing more than clever user interfaces around basic CRUD operations — something that a lot of development tools seem to make use of. By contrast, in the desktop applications world databases (SQL etc) play very much a minority role. And when they do play a role, it is usually via a client/server pattern, rather than embedded. (Even Sun's own article "Using Java DB in Desktop Applications" provides nothing more than an unimaginative address book application as an example.)
When programmers from the hugely popular EE community look over the garden fence at their minority SE neighbours, they are surely going to be a tad confused. After all, the EE crowd spend all day hammering in nothing but nails, so they're likely to look at something like Swing and ask "why it is so very very un-hammer-like?"
If SE is truly the edition of Java aimed at the desktop, and most real desktop applications (browsers, players, word processors, video editors) are not database heavy, why is Java DB being included in the SE JDK? Is it, perhaps, because those who influenced the decision spend too much time banging in nails, and now think the key to making SE more popular is to turn it into a hammer?