java - Difficulties understanding the renderers mechanism of swing's JTable and JTree

Question

Often when using JTable or JTree, user define its own cell renderer.

It is very common to inherit user's component from DefaultTableCellRenderer, and implements the renderer method getTableCellRendererComponent. It turns out that DefaultTableCellRenderer in fact inherits from JLabel, thus returns itself (this) when called to super (at the render method) and thus user's renderer can similarly returns itself (this) as well.

And it all works well.

My question is how can it be?

Each time this method is called by the table, it is given different parameters, and the output label is changed as function of these parameters. If it is indeed the same instance of the label – shouldn't it be changed according to the last call to this method? Wouldn't it mean that all of the table's cells are infect composed of the same label instance, which holds the same value (value of last call to the renderer method)?

I have searched the web, and dig within Swing's code, and could not find any act of clone or copy constructor that actually duplicates the output label. I could not find any evidence that (perhaps) swing uses reflection in order to re-instantiate the renderer each time from scratch.

I have read the Swing's tutorial on JTables, and there I could find the next lines:

You might expect each cell in a table to be a component. However, for performance reasons, Swing tables are implemented differently. Instead, a single cell renderer is generally used to draw all of the cells that contain the same type of data. You can think of the renderer as a configurable ink stamp that the table uses to stamp appropriately formatted data onto each cell. When the user starts to edit a cell's data, a cell editor takes over the cell, controlling the cell's editing behavior.

They give a hint, that indeed what I am saying is correct, but do not explain how its actually being accomplished.

I can't get it. Can any of you?

Answer 1

It's an implementation of the flyweight pattern.

When the JTable repaints itself, it starts a loop and iterates over every cell that must be painted.

For each cell, it invokes the renderer with the arguments corresponding to the cell. The renderer returns a component. This component is painted in the rectangle corresponding to the current table cell.

Then the renderer is called for the next cell, and the returned component (which has a different text and color, for example), is painted in the rectangle corresponding to the cell, etc.

Imagine that each time the renderer is called, a screenshot of the returned component is taken and pasted into the table cell.