
Java Swing comes with "pluggable look-and-feel technology", which essentially boils down to the fact that interfaces can be "skinned" (although this is simplifying a tad) and is therefore, extremely flexible. By default, Java ships with a cross-platform look-and-feel (LAF), which means your apps can look consistent across all platforms, or LAFs that mimic the look of a specific platform, say Windows, for example. However, one of the chief complaints of Java desktop applications is its "look". It basically stems from two issues:
Bryan, you have good points, although I'd like to address them too:
1) The Metal look and feel has never looked good, not even when it was first released. It's always made a bad impression. With its dark tones, poorly rendered non-standard fonts and unattractive widget sets, it makes an instant bad impression. Ocean has fixed the colour issue, but none of the others.
The non-standard fonts were obviously bundled to give the option of a standard multi-platform set, so that you can guarantee that interfaces will have the consistant looks and layout across platforms. Different fonts may alter layout. You can't rely on certain fonts existing on all platforms (this is why web sites often suffer with layout issues). The other reason is because those fonts are pretty rich in lots of languages other than English. Because Java relies on Unicode, it had to make sure that its fonts could render the characters. Admittedly, the bundled fonts don't have all the glyphs, but they're better than many. This may or may not be important for your app.
I'm confident that the looks will continue to improve in house. Of course the Swing team has a lot of other areas to work on and limited resources. Fortunately, there are a few decent 3rd party LAFS that'll tidy up your interface nicely
2) A lot of Swing developers go so far with the MVC paradigm, but fail to make the final jump: that is, to run the business logic in a separate thread, so the GUI can remain responsive. The reason for this is bad documentation from Sun. The Swing developers created the "SwingWorker" class many years ago, but it's never been included in Swing, nor has it been mentioned in official Sun documentation, which for its part does not highlight the need for multi-threaded GUIs enough.
Consequently, a lot of Swing apps freeze at every button press for no good reason.
You're right. SwingWorker appeared in 1998 IIRC. It's being included in the next version of Java (1.6).