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?
3 Answers
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 arevalidate
each time the cell is drawn. This would greatly decrease performance because therevalidate
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 thevalidate
,invalidate
,revalidate
,repaint
, andfirePropertyChange
methods to be no-ops and override theisOpaque
method solely to improve performance. If you write your own renderer, please keep this performance consideration in mind.

- 302,674
- 57
- 556
- 614

- 321,443
- 19
- 166
- 288
-
1@Eva: I suggest that you uncheck my answer and switch the answer check to camickr's post. It's right on the money. – Hovercraft Full Of Eels Oct 06 '11 at 03:26
-
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 ;-) – kleopatra Oct 06 '11 at 10:10
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...

- 283,665
- 25
- 256
- 373
-
-
2@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. – Hovercraft Full Of Eels Oct 06 '11 at 03:05
-
1+1, execpt non-opaqueness is not a benefit. The label needs to be made opaque so the setBackground() method will work. – camickr Oct 06 '11 at 03:06
-
1@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. – Hovercraft Full Of Eels Oct 06 '11 at 03:07
-
2Extending 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. – camickr Oct 06 '11 at 03:07
-
1@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. – Hovercraft Full Of Eels Oct 06 '11 at 03:09
-
1@camickr obviously, I disagree :-) as to opaqueness - DefaultTableCellRenderer uses a trick (again from the times of performance paranoia) – kleopatra Oct 06 '11 at 10:17
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 :-)

- 51,061
- 28
- 99
- 211
-
+1 agreed with Do-not-subclass, but I don't agree with performance_par.. what, on todays PC, – mKorbel Oct 06 '11 at 12:49
-
@mKorbel 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? – kleopatra Oct 06 '11 at 12:55
-
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 :-) – mKorbel Oct 06 '11 at 13:25