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.

GlazedLists is not "GUI-Lists"!

This is a post in Praise of GlazedLists - at least the concepts it embodies!

It took some time before I "got" GlazedLists.

I had read several articles about GL, and went to a JavaOne 2008 talk about it, but I still didn't actually grasp it: I feel that GL's presentations always centers around GUI aspects, in particular list-views and other boring stuff. This was not a good way to sell it to me: I weren't a particularly huge fan of "binding frameworks" and the like. However, I did see something through that GUI-haze, and when I finally did get down into GL, I pretty much immediately rewrote my current project to use it from the core outward! GL's concepts have nothing to do with GUI in themselves! It is just that the concepts are really very handy when it comes to several GUI aspects. I now believe GL have utility for any system which have a state consisting of a dynamic set of entities - not only for the "last mile", the actual display to the user, but as a core tool to build ones entity handling on.

The main concept of GL is actually not very "big" as such. I'll try to formulate a phrase that would have had me get the concept:

 " GL is at its core a modifiable List of objects, where sorting (reordering), selections (filtering) and transformations can be applied in a chain, resulting in new list views of the parent list, and the entire chain of lists is kept updated no matter where modification methods are invoked on that chain, by propagating the incremental change events internal to the chain, not needing an external event structure. "

Was that understandable?

Think about a system that has a List-of-Customers in the base. You then sort that list based on the customers' last name, getting a new list. Then you filter the list, for example selecting all the customers of age 40 or more. Yes? This resulting list is used often, so you keep a reference to it, "caching" it so to speak.

But then you get a new customer.

If you don't know GlazedLists, you now immediately think about some "NewCustomerEvent" that the container of the base list fires, on which the cache-holder listens, and upon receiving such events, it does the filtering, then sticks it into the list at the correct sorted position. Then you start thinking about customers that want to leave, and realize that you need a "CustomerDeletedEvent". And then, what if the customer was entered with the wrong name or age?

If you do know GlazedLists, you just smile! :-)

The base EventList gets the customer inserted, and sends an internal event up to the listeners, and first hits the SortedList. Here it is inserted at the correct position, but the sortedlist propagates the change further, up to the FilterList, which applies the filter, and now both the intermediate list and the age-40-filtered list is updated, "just like that". You may even change the sort-order, or the filter, and things are always correct.

You may also hook onto the event fire system at any point.

Now, this happens to be exceptionally useful for GUIs where it can keep different views "magically updated" when the internal state of the system changes, and GL also have lots of such utility classes that handle common "binding cases", but the main concept is useful for pretty much any stateful system that have dynamic set of entities as its state.

So, yes: Everyone should check out GlazedLists, not only the die-hard Swing/SWT GUI developers! It is definitely a tool that should be in any serious coder's tool chest blah blah..!