Why do cell renderers often extend JLabel?

Question

I noticed this is common. For example DefaultListCellRenderer, DefaultTableCellRenderer, and DefaultTreeCellRenderer all use it. Also a lot of the custom cell renderers I see online use this as well. I want to use a custom TableCellRenderer in my code, but I'm confused about whether I really need to subclass JLabel. What's the benefit of subclassing JLabel?

Answer 1

The API for the DefaultTableCellRenderer states:

The table class defines a single cell renderer and uses it as a as a rubber-stamp for rendering all cells in the table; it renders the first cell, changes the contents of that cell renderer, shifts the origin to the new location, re-draws it, and so on. The standard JLabel component was not designed to be used this way and we want to avoid triggering a revalidate each time the cell is drawn. This would greatly decrease performance because the revalidate message would be passed up the hierarchy of the container to determine whether any other components would be affected. As the renderer is only parented for the lifetime of a painting operation we similarly want to avoid the overhead associated with walking the hierarchy for painting operations. So this class overrides the validate, invalidate, revalidate, repaint, and firePropertyChange methods to be no-ops and override the isOpaque method solely to improve performance. If you write your own renderer, please keep this performance consideration in mind.

Answer 2

JLabel has all the firepower that they need and then some -- it handles text and icons, it can center itself, it has non-opaque background by default,.... and I could go on and on...

Answer 3

Because everybody - even the early Swing Team - is entitled to do thingies the wrong way occasionally :-)

And it is wrong to extend a component instead of implementing the renderer interface and let that implementation delegate to a component (which might be a specially implemented JLabel with all the whistles as they deemed to be necessary, personally I'm unconvinced). We're all still suffering from that bad implementation decision - the ominous "color memory" of DefaultTableCellRenderer is a direct consequence.

So: Do-not-subclass-someComponent-to-implement-someRenderer. Especially not for someComponent == DefaultTableCellRenderer, it is broken!

BTW, SwingX does it right :-)