Swing

From APIDesign

Swing is standard GUI for Java (in spite of many seeing the future in JavaFX; while everyone should be lookign at DukeScript!). What do you think, is Swing following the MVC paradigm or not? Recently Swing and JavaFX interoperability has been greatly improved.

Listen to podcast #2: to learn about our take on Swing and its poor reentrancy. Find out what it may mean for your own API design and especially Runtime_Aspects_of_APIs that you create. Learn to fight with that problem by maximizing the declarative nature of your API.

Example of Bad APIDesign

Few readers of TheAPIBook complained that it is too UI oriented as some of the examples are about Swing. True, but it is hard to find better examples of bad API Design. Swing is designed in a way SmallTalk people think about design and re-use. All methods are virtual, one can override them. There are duplicated helper methods which can be overwritten as well.

This all has one big problem. It is a braid of virtual methods calling each other. An [[OOP][object oriented]] spaghetti code. One needs Swing sources and a way to debug everything to understand what is actually happening in the framework. E.g. the learning curve is high and doesn't support much of cluelessness (yet I have to admit it is possible to do some trivial stuff in clueless mode).

This also has implications for the maintainers of the Swing framework. They have to assume everyone can override anything - almost like in case of APILessAPI where one can literally change anything. Sometimes people do and then weird code paths get executed. That means a maintainer of Swing has to assume the worst: changing something in the code requires very careful sustaining engineers (sometimes it is even harder than evolving the Arithmetica class). Not every engineer working on Swing has attitude and there used to be a lot of incompatible changes in the past (when Swing was still in active development).

Maybe the wide openness of the framework is the reason why it has such a bad reputation.