Note WPF is similar — PropertyChanged event is an invitation to “query ViewModel and display updates“
If you use a swing timer to fire table update events, you will see, in log or debugger, that after every fireTableCellUpdated(a single cell), getTableCellRendererComponent() runs exactly once, on that single cell.
If you don’t use swing timer but use scheduleAtFixedRate() to call invokeLater(), which asynchronously calls fireTableCellUpdated(), you will see the same in the log file. However, debug session will likely show many fire() followed by a getTableCellRendererComponent(). This is illusion. It depends where you break-point — (Let’s say in both cases the event is scheduled to happen once a second. )
* If you break inside invokeLater’s Runnable.run(), you get confusing results. Scheduled tasks continue to call invokeLater() once a second, but your debug may suspend the EDT, so you might see many fire()
* If you break before invokeLater(), you should see one fire() followed by one getTableCellRendererComponent() — ABABABAB
No break point, then no surprise. Bottom line, each fire() is followed by a getTableCellRendererComponent() call. In plain English, after we fire each update event on a cell, that single “cell model” will get queried and rendered exactly once.
As in WPF, our code aren’t allowed to modify the visual component directly. Only way to effect a visual change is to update the model and fire events to invite “Hollywood” to requery the model and Notice the update.