Info

Tech entrepreneur, executive, and investor; father of eight children; Googler.

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.

Comments

8 Comments

Post a comment
  1. April 30, 2007

    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

  2. April 30, 2007

    Anjan: It absolutely does. There’s a ton of room for productivity frameworks on top of Swing in the marketplace.

  3. Glenn Vanderburg #
    May 1, 2007

    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

  4. May 1, 2007

    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

  5. Brendon McLean #
    May 1, 2007

    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.

  6. Glenn Vanderburg #
    May 2, 2007

    True properties might solve this particular case, but they wouldn’t solve the general problem.

  7. February 9, 2012

    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

  8. February 9, 2012

    D0aJem jijunoorhyxg

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS