Swing has failed. What can we do?

Come to talk about Swing, this article tells us what's wrong with it. For those who don't know, swing is Java's GUI toolkit. The major things Joshua Marinacci thinks are wrong with Swing are the following:

  • Swing apps are slow to build. Building a Swing GUI takes time because you have to do it programmatically. No GUI builder can do it reliably. While the extra day you spend writing layout code may not be much in the life of a six month project, it still matters. The GUI needs to go through many iterations, preferably as early in the project as possible. If it takes hours to make changes then the project probably will not slip behind due to the extra development time. Instead the extra iterations just won't be made, resulting in an inferior product.
  • Swing layout managers suck. GridBagLayout is particularly bad, though it's better than all the others. Layout is an inherently visual task that needs visual tools. I wouldn't layout a magazine with a text file, I'd use Quark. Why shouldn't I have a quality visual builder for my Swing app?
  • Swing apps are hard to maintain. Since there's no standard place to put everything a maintenance coder will have to make heavy use of the search function to figure out how the app goes together and where to fix things.
  • Swing is too powerful. In terms of extensibility it's very powerful, but the complex API gets in the way of simple tasks, something that turns off new or infrequent programmers. Swing is great as a theoretical toolkit, taking advantage of modern UI theory: factories, renderers, MVC, event handling, and internationalization. (though I wish the rendering and event handling was more virtualized). But this is really overkill for many day to day tasks.
  • No native features. Each platform has interesting native features that may or may not have analogues on other platforms. Java was originally designed with cross-platform wrappers around everything for two reasons: to ease the life of developers (you don't have to code something twice) and to stop people from writing Windows only Java apps. I agreed at the time but I now thing this reasoning is flawed. Given a choice between more coding to conditionally use a native features versus not having access to the feature at all, I'll take the extra work. (note: Apple has done a pretty good job here, but we need more.)
  • Swing apps have a bad history. The early applications gave Swing a bad reputation that still lives on today. So what can we do about it? How do we counteract all of Swing's current and historical flaws?

Thank god I never had to seriously use Swing (so far).