[JTable] TableCellRenderer behaviour different to vanilla swing

[tychobrailleur]

Describe the bug
When setting a TableCellRenderer for Object.class and that the model returns class java.lang.String (for example), the renderer does not revert to the default Object renderer:

This differs in behaviour from plain Swing where the Object renderer is used if no renderer for String has been set:

Getting around the issue is straightforward enough for my case (defining the renderer for the specific type), but this behaviour change may cause issues for people adopting darklaf.

To Reproduce
See https://gist.github.com/tychobrailleur/3bbde9442bfd2615049c1968723f6f3b
Commenting out the LafManager.install(new DarculaTheme()); line causes the DarkTableCellRenderer to be used.

Screenshots
See above

Additional Information:

• OS: macOS
• OS Version: 10.14.6
• Darklaf Version: 2.1.1

Additional context
N/A

[weisJ]

This is because the renderer is set for most classes separately. I think at one point I planned to have separate renderers but never actually implemented them. I can change it so only Object.class is associated.

One suggestion though. In my opinion implementing a custom *CellRenderer by overriding Default*CellRenderer is really bad practice. Especially if you only want to change minor things as borders etc. My approach would by to use a wrapper class using the default renderer of the Laf as a base. Something like this:

public class TableCellRendererDelegate implements TableCellRenderer {
    
    private final TableCellRenderer renderer;

    public TableCellRendererDelegate(TableCellRenderer renderer) {
        this.renderer = renderer;
    }

    @Override
    public Component getTableCellRendererComponent(JTable table, Object value, boolean isSelected, boolean hasFocus, int row, int column) {
        Component comp = renderer.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
        // Customizations here
        return comp;
    }
}

        table.setDefaultRenderer(Object.class, new TableCellRendererDelegate(table.getDefaultRenderer(Object.class)));

This offers a LaF agnostic way of modifying the renderer component without losing consistency with other tables that use the renderer provided by the Laf.

For example (This is with alternating row background enabled. The default on macOS):
With default laf renderer:

With custom renderer extending DefaultTableCellRenderer:

With custom renderer using a delegate:

[tychobrailleur]

This is because the renderer is set for most classes separately. I think at one point I planned to have separate renderers but never actually implemented them. I can change it so only Object.class is associated.

This obviously depends on the backward compatibility requirements for darklaf, but this would be the least surprising behaviour for a developer migrating from vanilla Swing.

From my perspective, documenting the behaviour difference would be enough.

One suggestion though. In my opinion implementing a custom *CellRenderer by overriding Default*CellRenderer is really bad practice. Especially if you only want to change minor things as borders etc.

Yes, agreed, the decorator approach is quite neat. Unfortunately codebases out there (including HO) are a lot more complex than my little repro class, and tend to implement TableCellRenderer (probably because lots of swing tutorials promote that approach). ;-)