Java Authors: Esmeralda Swartz, Liz McMillan, Michelle Drolet, Kevin Benedict, Alfredo Diaz

Related Topics: Java

Java: Article

Should Java Assert that Network I/O Can't Occur on the UI Thread?

Doing network I/O off the UI thread comes at a price

Doing network I/O on the user interface (UI) thread is bad. Most developers know that and can tell you why; unfortunately, it's still done. At this year's JavaOne, one of the keynote JavaFX demos bombed because the network was slow, something that would be forgivable had the entire application's UI not frozen, which required it to be restarted, only to trip up again a few minutes later.

A colleague of mine who was watching the demo suggested that the Java language should assert that network I/O cannot occur on the user interface thread. At first I thought this kind of extreme, but the more I thought about it the more sensible it seems.

Doing network I/O off the UI thread comes at a price; this extra work probably means that developers often just slam their code together and hope it doesn't crash. The application has to spawn a background thread to do an I/O that can communicate with the display, via the user interface thread, to update the display, perhaps adding rows to a list or painting in a graphics context. If, while the background thread is doing I/O, the user indicates that they wish to run a different search or get, the program has to cancel the old request and start a new one. This is often the hardest thing to do well and the one most often overlooked; just ask anyone who has pressed the "Cancel" button on a dialog when a task has just begun, only to watch the progress bar happily clock its way to completion before the application realizes that the task has been cancelled, whereupon it dutifully ditches the whole operation that, ironically for the user, they may now want to see.

Because it's hard to do good network and UI programming, developers often skip doing it well. This kind of sloppy programming manifests itself in many ways, from e-mail clients opening large attachments on the user interface thread without allowing any kind of cancel of ability to carry on working, to lists and trees that go and fetch all of their content from a slow network on the UI thread, preventing any further interaction with the GUI till the request is complete. It's not quite the blue screen of death; rather it's the "white screen of unconsciousness" - when the UI won't paint as the helpless user drags around dialogs in front of the application, which after a while the OS may realize is errant and reports it as "not responding." The application isn't broken; it's just waiting for a network request.

Java is an incredibly versatile language, which is its biggest strength; however, to write a good client/server application is still "caveat programmer" where the developer has to write lots of boilerplate code and make judgements about which I/O will and won't be slow. What if my colleague's hypothesis is right and all I/O should assert that it can't be run on the user interface thread, forcing developers to write better client/server programs. Users would get better software, and the language specifiers would soon be putting frameworks in place that could replace and supersede all of the boilerplate grunge out there that deals with deferred table population or cancellable polling dialogs. This would remove concerns and issues from the programmer about long-running blocking UI tasks by enforcing that all potentially slow I/O has to be run on a separate thread. Hopefully as a result all the classes and frameworks for painting graphics, filling lists, and dispatching tasks are built into the language to work this assumption and don't require forcing or finagling to become good citizens.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
collin fagan 12/10/08 10:56:18 AM EST

The real issue is that the synchronous programming model fails in this type of situation.

I can see two options:

1. A completely asynchronous system. There is an asynchronous I/O systems that is part of NIO.2 (http://java.dzone.com/articles/hold-until-dec-8-tricks-and-ti). Making I/O into events would allow you to register I/O callbacks that could deliver data to the UI thread.

2. Make sure Swing is re-entrant and allow systems like foxtrot (http://foxtrot.sourceforge.net) which promises a synchronous programming model by spawning new threads to process the event queue instead of the worker task.

Unfortunately no one has ever succeeded in creating a multithreaded UI toolkit.

developer.dude@comcast.net 12/01/08 05:22:49 PM EST

It is not hard to do good network and UI programming - it is just *harder* than doing mediocre to bad UI programming (depending on the framework).

I do not support the idea of asserting that network I/O not be run on a UI thread because it is possible that you might actually want to do that, and it should be up to the coder to know this.

I *do* however support an assert that non-Swing event threads should not access "realized" Swing components (although most Java UI is not Swing or SWT anymore).

I have manually placed asserts in both network comm code and UI code to prevent these common mistakes - but I want the flexibility to choose.