Jim Cross

Over a year ago I switched to a new web hosting company after numerous problems with the old one.

The problems with the old company which will remain nameless were detailed in my first post on this site.

In that post, I indicated that I would tell how the new company was working out.

I'm delighted to tell that the new company has exceeded my expectations and has been better than any of my previous web hosting companies. They are outstanding on price, support, and most importantly up time.

This is a completely unsolicited and uncompensated endorsement for aplus.net.

The Java desktop application has been a neglected, sometimes ignored, part of Java development. Many Java developers, once they learn the language fundamentals, head straight to server-side Java where there has been much excitement in recent years. They may pick up a little knowledge about the Java Foundations Classes (JFC) or Swing somewhere along the way, but seldom see a compelling rationale to develop a desktop application. Developers who are interested in the desktop as a platform on the other hand tend to focus on platform specific solutions (usually Windows, which dominates the desktop) and fall back on platform specific tools.

The fault for this state of affairs is not wholly with the developers. The Java desktop application to an extent is a victim of history. Java from the beginning was associated with the Internet. When Java was first introduced, many, developers included, equated Java with Applets, the mini-apps that run in browsers. Combined with this misconception were the limitations of the early versions of Java. Early Java often failed to perform well, had an inadequate event handling model for sophisticated desktop applications, and lacked many of the widgets available in one form or another on the various platforms. To remedy these problems, Sun created Swing. Almost at the same, however, Sun introduced Enterprise Java. Enterprise Java caught on in a big way. It capitalized on the association in many developers’ minds between Java and the Internet. It provided a solid and increasingly robust, portable, software platform for developing the back ends of web-based applications. Between the frenzy of the Internet and problems of beleaguered IT managers struggling to maintain software across enterprises of desktops, web-based development took off and developers immediately gravitated to it. Adding to this has been the recent development of more robust client-side browser scripting techologies such as Ajax. The result of all of this is that the Java desktop application got caught in the backwater – filling a niche role here or there but never really maturing as a major platform of choice.

Nevertheless, I would argue that there are still roles for Java Desktop applications.

Desktop Java applications are ideal for the following circumstances:

1.The application needs to be able to run disconnected from the server

A web-based application must be connected to the Internet or a local area network for it to operate properly.

If the application needs to run on stand-alone machines or disconnected part of the time, a desktop application would be a good choice.

For example, a sales support application might be intended to run on the laptops of sales people. A sales person might connect to a network and a server, maybe even a web-based application, to download and sync local databases with a master, centralized database. The person might then disconnect and go on the road with the laptop. The application continues to function in stand-alone manner while disconnected.

2.The user interface is too demanding for a web-based application.

While sophisticated interfaces can be produced with web-based applications, HTML and JavaScript are more limited than a desktop application and are more difficult to program and develop if the interface demands are significant.

Different browsers have different levels of support for HTML and JavaScript. In addition, any user can turn JavaScript functionality off completely and effectively break an application.

Obviously a drawing application or a word processing application would typically require a responsiveness and control over the display unattainable in a web-based application unless the features it supported were drastically below the industry standards for such applications.

Even more ordinary business applications, however, may need features that are difficult to implement in a web-based application. Applications that rely on interactive population of list boxes and drop downs are particularly difficult to deploy as web-based applications. For example, if the contents of a list on a web page are dependent on other selections on the page, none of the alternatives available to the developer is good. Although in some cases the JavaScript can be seeded with variables representing the various combinations of selections a user might make, the developer usually faces the choice of returning to the server every time the user changes a selection. This makes for a relatively unresponsive application and possibly unhappy users.

3.The application makes high demands on disk or memory.

Let’s imagine a large retail chain with a thousand stores and each store has twenty departments. Each department is required to create a weekly purchase order that the head of the department starts and works on for several days during the week before submitting it on Friday. Each purchase order may have hundreds of items and each might have multiple special conditions attached to it, such as discounts for ordering in certain quantities or associated items that should be ordered with an item to maximize sales. Ideally the department head would like to be able to manipulate the purchase order in spreadsheet-like fashion to monitor the overall cost of the orders and to stage the delivery times for the items ordered.

While this could be implemented as a web-based application, twenty thousand individual order worksheets would need to be maintained in the central database. In addition, each worksheet would need to be loaded into the browser with fairly sophisticated JavaScript to maintain the totals. Each change to the spreadsheet might need to be committed to the central database. The traffic back and forth between the client and the server might degrade the performance of the application and the database to an unacceptable level.

A better implementation might be to store the worksheets locally, manipulate them in a desktop application in local memory on the client machine, store the interim results locally, and only commit the final results of ordering process once all of the decisions about the weekly order have been made.


4.The application requires access to local machine resources.

If an application needs to access local resources, such as files, directories, or the printer, it would be good candidate for a desktop application. An example might be a file utility, such as a zip utility or an XML editor.

Web-based applications really have no ability to access local resources besides uploading and downloading files and using the browsers to send printed outputs. Applets are limited by browser security and must be signed to access files and the printer.

On the other hand, an installed Java desktop application has virtually full control over the file system and the printer.

5.The application is primarily of a personal or individual nature.

Although it is possible to put personal diaries, exercise logs, or household budgets on the Internet, it makes little sense to do so. Applications that are not multi-user and have no appreciable benefit to gain from collaboration with other users have no compelling reason to be located on a server or a web site.

Placing such applications on a web site requires the user to place personal information in a public place. It also requires a network connection and a web site to be up for the user just to be able to use the application.