The Source for Java Technology Collaboration

As the new infrastructure contains project-level wikis, this main wiki will be shut down in the near future. For wiki page export and general wiki questions please contact the site admin at
Home | Changes | Index | Search | Go


A collection of general rules to follow when using and designing Swing/X. They are in no particular order, are kind-of FAQ on a higher level then the how-do-I, usually result in hefty debates (by the uninitiated of course [grinning]). They are formulated as imperatives - though there's always a grey zone and special contexts where they might be transgressed. In my experience, those transgressions never pay in the long run: most of the time when I did, I ended up with a sigh "you should have known, idiot!" and fall back to stick to the rule.

todo: follow a proposal from a thread in SwingLabs forum - for all "Don'ts" offer a "Do" alternative.


Do not subclass AWT/Swing/X Components for application needs

All members of the Component hierarchy are designed to be used instead of subclassed. They are tailored to serve a special purpose in a general manner.


  • hack around bugs
  • need to interfere with the painting - this reason will vanish after full integration of Painters.
  • make them play nicely with GUI-Builders (that's from hearsay, not personal experience)


Do not use component.setXXSize

The getXXSize methods must provide reasonable size requirements based on and calculated from the Component's internal state. Explicitly calling setXXSize short-circuits any internal calculation, leaving all burden to return reasonable values on the code which called the setXX. They are used by LayoutManager as hints to balance the actual layout, including locating and sizing the individual components. If one LayoutManager can't cope try a different instead of bullying the component.


  • "true" compound components may decide to force sizes of intimate children (an example is JComboBox) - which is not really a transgression because they do take explicit responsibility for the compound component as a whole.


Do not implement model listeners in view classes

Todo: formulate more clearly! The idea is to distinguish "someclass-uses-someinterface" and "someclass-is-someinterface". The former is the case if the view listens to the model to synch internal state. The latter is the case if the view is meant to expose the interface api for usage by client code.

The drawbacks:

  • the class api is littered with "accidental" public methods (the listener callback methods). Which normally are not meant for usage by client code.
  • requires subclassing if modified listener reaction is required (not completely conclusive, the simple stage of the alternative has the same implication, see below)

Instead, use a field referencing the listener. To instantiate the field use a factory method. If there is "change expectation", make the factory method protected to allow subclasses to hook into. If the change expectation manifests itself, the field can be made a property.


  • the view really is-a type of interface, that is if the interface api is actually meant for usage by client code

Do use Action instead of ActionListener

Object Orientation

Do not violate super's contract

Do implement super's constructors

When inheriting from a Swing class to create a SwingX variant implement constructors that appear in the parent unless doing so is counterintuitive. For example, JXLabel should support constructors with the same parameters as JLabel, while JXTreeTable should not implement constructors based on JTable or JXTable, since doing so would not be useful.


Do use the highest abstraction available

Topic SwingLabsImperialRules . { Edit | Ref-By | Printable | Diffs r5 < r4 < r3 < r2 < r1 | More }


Revision r5 - 2011-01-14 - 09:39:49 - Anonymous_20User
Parents: WebHome > SwingLabs