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?

Fridafriday

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.

Photocathode

@Eva: I suggest that you uncheck my answer and switch the answer check to camickr's post. It's right on the money. – Annalist

personally, I don't believe in any of that. It stems from height of performance paranoia (though SwingX has custom rendering components which do override those methods, to feel safe ;-) – Outpost

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...

Annalist

Why not create a JLabel within the class? – Fridafriday

@eva: Ah, I see -- composition vs. inheritance... I don't know the score on that one. Perhaps they're overriding a key method such as paint or paintComponent. The source may tell. 1+ for an interesting question by the way. – Annalist

+1, execpt non-opaqueness is not a benefit. The label needs to be made opaque so the setBackground() method will work. – Photocathode

@camickr: I always thought that being non-opaque was good so that the background of the JList or JTable itself could be seen, but you are right, when cells are selected, a background color is shown. – Annalist

Extending a JLabel is beneficial because many methods are overriden to make the rendering of the label more efficient. Take a look at the source code if you want to see all the empty methods. – Photocathode

@camickr: please change your comment above to an answer, as it seems to me that it truly is the strongest reason, and thus the strongest answer to the OP's question. – Annalist

@Photocathode obviously, I disagree :-) as to opaqueness - DefaultTableCellRenderer uses a trick (again from the times of performance paranoia) – Outpost

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 :-)

Outpost

+1 agreed with Do-not-subclass, but I don't agree with performance_par.. what, on todays PC, – Lm

@Lm dont understand what you "don't agree with ..." - are you saying "the empty method overrides in core DefaultXXCellRenderer are necessary" or are you saying the opposite? – Outpost

1) agreed with everything about Renderer and SubClassing 2) don't agreed with performace impact from todays PC (visible impact) to the LCD display, 3) matter of fact is that modern HW to minimalize visible output to the screen from excelent, clear and optimalized code and as from mess :-) – Lm