One of the best parts of writing frameworks around Java’s Swing GUI toolkit is how often components don’t actually follow the component contract.
For example, JComponent defines a FocusListener which predictably enough fires an event when a component receives and loses focus. Yet, many components in Swing and its ecosystem (e.g., JComboBox) simply fail to fire a focus event. Why? Because they are composite components (i.e., they are comprised of several components mashed up together) and they expect you to get some of the internal components and register the FocusListener on one of them. Mind, this is rarely documented, adding to the fun.
No no no no! I wish Swing’s team published some kind of “requirements to be a component” document or “best practices” document that did away with this foolishness. Writing a framework that treats components generically is next to impossible (i.e., requires a special adapter layer that makes all components obey some kind of contract) thanks to all of this–to say nothing of the poor newbie.
Ben Galbraith 
hi ben,
does this NOT give scope to someone who wants to write the next onTopOfSwing framework, like say, spring RIA ?
And, like RodJohnson, if someone writes a decent book about that framework/library, then writing swing apps becomes a lot more easier.
BR,
~A
Anjan: It absolutely does. There’s a ton of room for productivity frameworks on top of Swing in the marketplace.
Language support for expressing contracts is one way to approach this kind of thing, but there’s another way that isn’t as widely used as it should be.
If you’re building a library that’s meant to be used and extended by third parties, write a set of abstract unit test classes that test for adherence to the contract. This is usually pretty easy to do. Then recommend that people extending your classes or implementing your interfaces (including your own group, of course) use those tests. A new testcase that extends the abstract one and overrides setUp is usually sufficient, and then all of the inherited tests will be run against the subclass or new implementation.
—Glenn
If Java had proper properties this wouldn’t be an issue. I mean properties that can reference complex objects, such as an embedded JTextField, wich properties itself can be drilled down to and set/unset, and so on..
Swing was made for flexibility without considering tool-ability. This can only be fixed with a refactor to Swing 2.0. It wouldn’t take much effort compared to rewriting a new GUI toolkit, but it would solve so many problems.
Cheers,
Mikael
Spot on. I’ve run in the same thing many times. As a rule, I always add addFocusListener delegate methods to all my compound components which simply delegate the call to the textfield.
True properties might solve this particular case, but they wouldn’t solve the general problem.
affordability – you don’t want a game thats $ 1000playability – you don’t want a game with 1000 rilasaccessebiluty – where can you get the game?age limits – is the game for kids or adults?# of players – self explanatory
D0aJem jijunoorhyxg