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?

Colonist

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.

Gonsalez

+1 The screenshot metaphor is a good one. I thought the most used one was a 'stamp' but screenshot might be more clear – Paresis

Thanks. the metaphor certenly does the trick :). it is now understood. – Colonist

Answer 2

In adition to @JB's clear explication of how JTable and JTree use the flyweight pattern, note how both classes provide public methods getCellRenderer() and getCellEditor(). Examine these methods to see how JTable uses Class Literals as Runtime-Type Tokens to select a renderer or editor by class, if none is specified by column. Internally, JTable uses a Hashtable defaultRenderersByColumnClass for instance storage.

Shrader

Answer 3

After some digging, found the next implementation note from DefaultTableCellRenderer documentation:

Implementation Note: This class inherits from JLabel, a standard component class. However JTable employs a unique mechanism for rendering its cells and therefore requires some slightly modified behavior from its cell renderer. 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.

This is essentially what JB explained above.

Thanks for the (quick) answers

Colonist

Similar optimizations are are found in CellRendererPane, used by the TableUI delegate and illustrated here. – Shrader