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.