Rant: Who Designs These UI Frameworks Anyway?

I've been working with a few different UI frameworks lately as part of building Metawidget, and I've noticed something...

Building Consensus

First let me state some things I hope we can all agree on:

• Rule 18 of Effective Java: Prefer interfaces to abstract classes
• Rule 16 of Effective Java: Favor composition over inheritance
• The industry trend toward POJO-based development is a positive one

If you accept all these, then I have a shock for you: most UI frameworks ignore them. Oh sure, UI frameworks love defining interfaces for you the developer to have to pass them (MouseListener, SystemEventListener etc) but when it comes to adhering to these rules themselves, internally? Not so much.

Swing of Doom

Here's the challenge: how come hardly any UI frameworks define their widgets in terms of interfaces, as opposed to abstract base classes? Why isn't, say, Swing's JComponent an interface? By all means have a JComponentImpl as a convenience class, but don't force me to extend from it. Many programming languages use single-shot inheritance, so if you constrain my single-shot I'm screwed if I want to develop, say, some cross-platform UI functionality or a composite component without putting everything inside a JPanel.

It's Not Just Me, They're All Doing It!

Sure you could argue this is a corner-case, and that Swing predates much of the modern wisdom, but just look at this list:

Where are the lightweight, POJO-based, interface-based (or even, gasp, annotation-based) UI frameworks?

A Shining Example To Us All

A twist to the tale: I did manage to find one UI framework that implements its base widget using an interface. What is this enlightened, cutting-edge, modern framework you ask? Why plain ol' Java Server Pages of course! Its base Tag is an interface, with convenience class TagSupport. JSP, eh? Before its time or what :)