Simon Morris's Blog

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.)

Comments

• I mostly agree with what you're saying here. However, if you think about where Enterprise development has been headnig the last few years, a lot of enterprise apps aren't deploying on Java EE, but on SE.

  Spring + Hibernate + Struts + some DB + Tomcat, and we're Done. Runs on the Java SE SDK (which conveniently, contains a database!). No need for EE or an app server. I think this is the experience a lot of webapp developers might be having of late, and hence they see the SE to be as much theirs as it is anyone else's (and why shouldn't they?).

  Perhaps we need a Java DE. : )

  Graham.

  Posted by: grlea on July 12, 2006 at 04:48 PM

• 
  Actually, I somewhat disagree.

  Certainly, the desktop applications cover the gamut of what many folks do at their workstation all day long.

  But, in truth, the markets for those particular genres are very mature and quite capable. Which leads to the point that from a development perspective, most desktop development, particularly in Java, especially in the corporate world, is not done in those particular fields.

  I don't think anyone is writing their own word processor, for example.

  Now, some specialized markets use graphic heavy applications, like market analysis, or oil exploration, etc. But in fact, those markets aren't particularly mainstream but rather extremely vertical, and small to boot.

  So what's left? What kind of custom development is common for the desktop?

  Same as it's always been. Back office database applications. CRUD stuff. Every business in the world is out there reinventing their own wheel to better serve their customer base, and computers are major tool in that process. Stuffing stuff in to databases and later reporting on it is a key mechanism.

  Now, many may have moved from the desktop to the web app (for whatever reason). I mean, if you think about it, CRUD via a Web App is really a miserable model (thus, 101 CRUD frameworks to make it less miserable).

  So, yea, there's a lot of email clients, word processors, video editors et al being used out there, but that's not where the majority of custom development is happening. The silent majority is the back office IT hacker trying to make their own company run more smoothly.

  Posted by: whartung on July 12, 2006 at 05:09 PM

• 
  Nice article, Simon :) I second you all :) In my experience (albeit mostly in retail and some telecoms), most Swing development is database front ends. But even a JME cellphone, surely you wanna log calls, save sms'es, maintain an address book, in an embedded database. And even for a "stateless" graphics only Swing application, assuming you have no users/roles/permissions (which should be in a database), what about logging to database rather than file?! Then you can search for events and exceptions using date ranges, severity, etcetera :)
  

  Posted by: evanx on July 13, 2006 at 04:29 AM

• What we need is a more modular JVM. It's silly to think that you can make a single SE JRE that "fits all", so you should be able to split up the runtime into modules. If your app does not use a DB, you're free not to include that module. It's not that hard. Just look at the OSGi framework for a SOA framework which enables this for Java code and Apache Harmony for a Java 5 SE VM that has componentized the whole standard API.

  Posted by: marrs on July 13, 2006 at 05:28 AM

• +1 on the need for a modular j2se.

  Posted by: eitan on July 13, 2006 at 06:30 AM

• I completely agree with Whartung. At least, that's what everyone I work with does all day long. Some have gone the way of the web application, but have discovered that the web functionality IS NOT what our users want. They use Outlook, Word, and Excel all day long, so they expect every application to function and respond in a similar fashion. Even combining the 20 or so of this years latest and greatest web framework trends doesn't get you that functionailty. Of course, it's all already there in Swing and now there's a simple and full featured test database to use included in the JDK. It's naive to think that all Java developers are building the next cool shopping cart and pet store app for Google.

  Posted by: evickroy on July 13, 2006 at 06:31 AM

• Very well put. It is really unnecesarry to include a database in the JSE what is really needed is a way to interface with databases and we already have JDBC. Thank you for publishing this article which represents the opinion of many of us.

  Estanislao

  Posted by: estanislaobosch on July 13, 2006 at 06:53 AM

• I was hoping this blog might raise some interesting replies, and sure enough I wasn't wrong. Thanks for some exceptionally well made points thus far. Like all good arguments, I can see there's a grain of truth in all sides of the debate. I've provided my thoughts on some of the comments below.

  whartung: I figured someone would point out that Java doesn't currently hold much of a foothold in the traditional desktop market. To keep the blog entry short I neatly sidestepped that issue, so let me deal with it here, as you were absolutely right to bring it up.

  My thinking is that if we are to abandon Java for traditional desktop apps and throw our weight mainly behind CRUD then we might as well withdrawn Swing and much of the JDIC improvements added to Mustang in favour of turning SE into a kind of 'EE-lite'. I think Swing/WebStart/etc provide the promise of re-inventing the desktop application into something which truly befits the multi-platform multi-device network age we live in. I'm therefore in favour of Java fighting to compete in the desktop space, rather than abandoning it to focus mainly on database apps - but to do this we need an SE implementation which is 100% committed to the needs of desktop developers. I'm not sure how including Java DB as standard helps the desktop. I wonder if it is nothing but bloat(?)

  evanx: Interesting points...but... most desktop applications don't log!! This may seem like heresy to web app folks, but in an interactive environment the question is "why would they?" 95% of desktop applications have no need to keep a history of events (short of an undo buffer) and errors are more appropriately reported directly to the user for immediate remedy. Some applications do keep a history of edits - but this data is more correctly stored inside the file associated with that data. (I do not want to have to export a database along side each Word document.)

  Even for those desktop apps which do occasionally spit out a logged message, does it really mandate a 2Mb API to do this??? In a server environment, where software runs unsupervised, then logging is important - but desktop apps are generally single user and interactive.

  As you noted, in an environment mainly centred around editing files, roles/permissions are usually determined by the underlying OS (user accounts, file permissions, etc) rather than an application specific database.

  Perhaps this just highlights how the desktop and web worlds are so very very different...?

  marrs: Well said. (Thank you!) I pondered on exploring the same issue in the blog entry, but figured it be a bit of a lenghty diversion. I was originally against breaking up the the API into downloadable modules, but I've steadily been won over to this argument. I think a general mechanism is needed for locating and installing packages automatically (not just standard API ones either.)

  Posted by: javakiddy on July 13, 2006 at 07:39 AM

• Simon,Great post (as always)... but once again I find myself holding a contrarian view with respect to JavaDB.
  I wrote desktop applications for many years... and in the early years we constantly invented our own "persistence mechanisms". These mechanisms worked very well, until we wanted to "mine" the data created by one application from other applications.The advantage of using a relational database as your ultimate storage technique (beneath and O/R mapping layer if you prefer) is that it's a very standard and well understood beast. If you share the schema definitions with another developer, they are probably going to be very successful in their attempts to extract whatever data they need from your data store.The same cannot be said if you choose to store your objects in some other way (for example, as serialized objects)... I know, I made this mistake on an application 10 years ago, and the poor folks who inherited it still curse me to this day ;-)

  I think the inclusion of the JavaDB simply makes it easier for new developers to get into the "Relational DB as the root of all" mindset. It's probably just a place holder for a "real" database like Oracle or PostgreSQL.

  
  -JohnR
  

  Posted by: johnreynolds on July 13, 2006 at 09:24 AM

• Hi Simon,I rather like the relational database model, I often create purely memory based tables, just for the query and referential integrity functionality. Also, I think the RDB is a superior replacement to a hierarchical file system, when data needs to be saved to disc. It also provides a nice universal representation, which can be easily shared between applications, XML pales badly in comparison.That said, the current crop of AJaX interfaces remind me a lot of the old TN3270 interfaces. I understand, forms are a generally useful business tool, and where they are needed, they are probably even the best approach. However, the typical desktop application is far beyond the form based paradigm. I think their metaphors are appropriate: I can create a form in a desktop, I cannot create a desktop in a form.Perhaps, with a whole lot of work, you might be able to get an AJaX application to behave almost like a DOS application, big deal. Java can allow a server to provide a complete remote graphical user interface, which is much like its local one, because in fact, it likely is.I think this is a case of those who do not know (computer) history, being condemed to repeat it.John

  Posted by: cajo on July 13, 2006 at 11:43 AM

• With regard to using databases as a persistence mechanism, I'm a tad confused. If you want a universally accesible format surely XML is superior for the file-centric world of the desktop? Sure, from the programmer's abstract 'application layer' point of view databases have their advantages, but how easy is it for the end user to take the underlying binary files and mail them to a friend or workmate (ala a Word doc, JPEG or MP3) and have that data be read by software on another platform, perhaps implemented in another language?

  (I have to admit my ignorance - is there indeed a standardised binary format for database files, or does each database implement its own underlying binary format? And how easy is it to move these files around anyway, like a desktop user would expect to? Aren't there generally multiple files per database, and aren't they usually on the verbose side?)

  I still maintain full relational databases have only a minority role in traditional desktop software (office/email/browsers/players/etc.) We've had desktop software for over two decades now, and few have noticed the lack of in-built SQL support in X, MS Windows, MacOS, etc. etc. Surely if relational databases were so vitally important on the desktop they'd have been embedded into every desktop OS as a standard component years ago? Why hasn't anyone noticed they are missing?

  Reading and re-reading over some of the comments, I do find myself swayed a little by one argument. If most real world Swing apps are indeed nothing more than glossy wrapping for a CRUD back end, then perhaps it would be pragmatic to include Java DB? However (!!!) I do feel this premise needs to be tested, as most Swing apps I have witnessed, indeed most Swing apps listed on "Swing Sightings", seem to be CRUD-less or CRUD-lite. Could it be that Swing Sightings etc. is not a true representation of what Swing is being used for?

  Posted by: javakiddy on July 13, 2006 at 04:13 PM

• XML is not superior to a database if you need for multiple applications to simultaneously access/update the data... Does that make sense?

  -JohnR

  Posted by: johnreynolds on July 13, 2006 at 05:24 PM

• Java DB is included in the 1.6 JDK to provide "developers" with a simple_to_use lightweight 100% Java database sytem available right there in the Java developermt kit - compressed under a 1MB, am not sure how this is turning the JDK into a hammer - Java DB is *not* included in the SE JRE package...Sure, developers can go and use other database systems (obviously) but I'd argue it is nice to have access to a lighweight database system supported by Sun which also implements the latest specs of JDBC (i.e. JDBC4)...and well if people don't like it, they can always issue a 'rm -rf' of the 'db' directory under the JDK home installation directory...

  Posted by: forsini on July 13, 2006 at 09:34 PM

• 
  Howya Simon! You're right that many desktop apps don't log, maybe in the event of an exception, they just report to user with a "Details" button to view exception, and/or they popup an email to support@ using JDIC.
  Ps. I'm gonna write a further response on my blog, about the diversity of desktop apps, because you have raised such an interesting discussion, thanks for that!
  

  Posted by: evanx on July 14, 2006 at 05:28 AM

• I agree with Graham, Java SE is favored for much of the web development that don't need all the enterprise features from EE. Maybe we need a Java WE (web edition).

  I also see the JDK as a toolbox rather than a tool. You take what you need to get the job done and you don't have to bother with features you don't need. Developing web apps, I don't need the swing features, but their inclusion has never really bothered me.

  Posted by: trisberg on September 12, 2006 at 04:49 AM

This work is licensed under a Creative Commons License.