Swing should be a standalone library

The public parts of AWT and Java2D should be Java’s sole interface to the native GUI system. Java2D is already accelerated, and one even have some amount of control of such features with VolatileImage and friends like BufferStrategy. I would personally don't mind more intimate control of and access to the hardware. And I wouldn't be terribly sad if there had to come a Java2D 2 and 3 to handle any new types of GUI hardware, in the same way we have java.io, NIO and More New IO.

Swing ought to be a standalone, separate, pure java library, built on top of AWT/Java2D. Actually, initially Swing was just that; a library that you had to download on the side, w/o any hidden magic. It was called JFC, Java Foundation Classes (to compare against MFC, Microsoft Foundation Class, a tradition that was upheld with JSP vs ASP and others) and is actually still available. With the release of the absurdly named "Java 2" (which gave rise to version names like "Java 2 SDK v1.3.0" and "J2SE v1.4.0"), the JFC was included with the java releases, and the downward spiral of spaghetti was started.

Even if one cannot at this point drop the backward compatibility for the current Swing (at least not for a couple of major java versions), one could simply abandon it - and make a refactored Swing2. Here one would drop all the extreme amount of cruft that has accumulated, and fix the problems and annoyances and incorporate the knowledge gained through years since Swing 1 in 1997. The native code of Swing that obviously crept in as long as Swing was a integral part of the JRE, would be ripped out and the necessary parts "ported back" to AWT/Java2D. Importantly, however, this new Swing 2 shoud never be included in the JRE: Applications would have to include it themselves. I know what you immediately think, but this is not as awful, sizewise, as one first might believe. By separating the subsystems themselves into distinct packages (check out Project Jigsaw), you'd get better code with fewer interdependencies. Swing needs all the separation it can possibly get. By using jarjar, only classes used by the application would be included. Possibly proguard can help shrink the jar size, and Pack 200 shrinks jars by about 60%. You probably already have 10-20 external jars for any little app. Given the enormous potential resulting by separating Swing into an external jar, I'd love to depend on this jar too!

Swing1 could at some point become an optional element that itself needs download. Given that the JRE by v6u10 goes exactly in this direction, that wouldn't be a problem at all. And I would already look forward to the complete rewrite in Swing3 - or me and some friends would fork Swing2 into Swing2NG or something if we didn’t like the direction Sun's Swing was taking - thereby getting progressive dynamics into the development!

On a related note: The project called Cacioavallo, proposed here by Roman Kennke, is a project which wants "to improve the AWT and Java2D interfaces to enable the implementation of external backends to AWT/Java2D". He (and apparently one more) finished it up, and it is now present in OpenJDK. This is awesome. Furthermore, he followed up by implementing AWT using Swing (all the widgets-parts). This has now been taken further to the point where to implement the entire "GUI Java", you apparently only need implement a single Graphics2D class onto a direct "pixel plane". All other is thus taken care of. He "proofed" this by making a full implementation using DirectFB (and had already made a version running on VxWorks).

Actually, pretty much everything this guy does seems brilliant: http://kennke.org/blog/.

This stuff reminds me of two extremely interesting projects which are similar to each other and yet the complete opposite of each other: SwingWT and SWTSwing. Too bad those seem dead.