AWT: Java's Achilles Heel

If anything can kill Java, the Abstract Window Toolkit is it. AWT is a such a seriously flawed tool, Java's promise of cross-platform compatibility will never be realized unless AWT is discarded, or at least substantially rewritten.

First, let me mention just a few of AWT's problems.

AWT s built on Sand

Or more precisely, it is built on Macintosh, Windows, and X-windows. AWT was obviously designed from the top down to provide convenient high level objects such as menus and buttons. Unfortunately, the design stopped just below the top; at the earliest opportunity, AWT reverts to using the native tools available on each platform.

Consequently, the detailed appearance of AWT widgets differs on each platform. This might be ok for a quick proof-of-concept demo, but finished, commercial quality applications ultimately care about every pixel.

Worse, the detailed behavior of widgets differs from one platform to another, sometimes in devastating ways. For example, on some platforms changing the text in a textarea immediately updates the display; in others, the display is not updated until the next normal update cycle (whatever that means!). So a program which updates a text area by repeatedly appending a few caracters will behave acceptably on some platforms, but will thrash unacceptably on others.

Even worse, the detailed bugs differ on each platform; on some platforms, a not-quite-correct program will seem to work, on others it will fail. In one case I studied at some length, a missing call to validate had no adverse effects on Windows-NT (using SDK 1.02), but manifest as very different looking display glitches in each of the other runtime environments I tested.

Finally, because of all the platform dependencies introduced by using platform-dependent substrate, all of the AWT implementations have quite different bugs in their implementation.

AWTs Event model is flawed.

AWT encourages each source of input (mouse, keyboard, network, window manager, your program's actions) to handle events directly; consequently, the application's data structures are likely to be traversed simultaneously by any number of different threads. This is a recipie for disaster. It is very difficult to correctly synchronize multiple threads, each of which could be doing anything; and when errors do occur, they occur in the context of some random peer's thread, not the thread "normally" associated with the application.

AWT needs a lot of new features, and lots more documentation

...But adding more on top of the existing mess will make the situation worse. For example, AWT's drawing model is impoverished; it allows only "draw" and "xor" mode, (and xor mode is buggy). It says nothing about blending, multiple buffering, color maps etc. etc. AWT says nothing about overall refresh management; when does an "update" occur?

Prescription: a two step program for JavaSoft

  • First, specify a small, precise, bit-level graphics engine, and require that it be implemented by all implementations of JVM.
  • Second, write one implementation of AWT in Java, compile it once, distribute it to all platforms.

    Nothing short of this will do. In particular, unless the fundamental graphics code applications actually use is the same, and not just similar, or written to the same spec, the graphics behavior that programs depend on will not be similar enough.

    More Ammunition

    comments/suggestions to: ddyer@real-me.net

    My Java page

    my home page