我注意到这很常见。例如，DefaultListCellRenderer，DefaultTableCellRenderer和DefaultTreeCellRenderer都使用它。我在网上看到的很多自定义单元格渲染器也使用它。我想在我的代码中使用自定义TableCellRenderer，但我对是否真的需要继承JLabel感到困惑。子类化JLabel有什么好处？
答案 0 :(得分：10)
API for the DefaultTableCellRenderer州：
表类定义单个单元格渲染器，并将其用作橡皮图章，用于渲染表格中的所有单元格;它渲染第一个单元格，更改该单元格渲染器的内容，将原点移动到新位置，重新绘制它，依此类推。标准
JLabel组件未设计为以这种方式使用，我们希望避免每次绘制单元格时触发revalidate。这会大大降低性能，因为revalidate消息将在容器的层次结构中向上传递，以确定是否会影响任何其他组件。由于渲染器仅在绘制操作的生命周期中具有父级，因此我们同样希望避免与绘制操作的层次结构相关联的开销。因此，此类会将validate，invalidate，revalidate，repaint和firePropertyChange方法重写为no-ops并覆盖isOpaque方法仅仅是为了提高绩效。如果您编写自己的渲染器，请记住这一性能考虑因素。
答案 1 :(得分：5)
JLabel拥有他们需要的所有火力，然后是一些 - 它处理文本和图标，它可以居中，默认情况下它具有非透明背景，......我可以继续......
答案 2 :(得分：4)
因为每个人 - 甚至是早期的摇摆队 - 都有权偶尔以错误的方式做事： - ）
错误扩展组件而不是实现渲染器接口，并让该实现委托给一个组件（可能是一个特殊实现的JLabel，它具有所有必需的哨声，因为它们被认为是必要的，我个人不相信）。我们仍然遭受了糟糕的实施决策 - DefaultTableCellRenderer的不祥“色彩记忆”是直接后果。
所以：Do-not-subclass-someComponent-to-implement-someRenderer。特别是对于someComponent == DefaultTableCellRenderer，它被破坏了！
顺便说一下，SwingX做对了： - ）