JRendererLabel behaves exactly like DefaultTableCellRenderer when it comes to opaqueness,
so actually I can't see a defect there. SynthTableCellRenderer is ... ehem .... quite
weird and Synth can't cope well with renderers which are not under its control, read:
not replaced by synth.
But the underlying defect is somewhere in SynthTableUI painting code: it does not use
the table's background color to fill the table's background. In the example, you can
see that in the area below the rows: with fillViewportHeight enabled (in java6, for java5
you have to override the table's getSomeThingTracks method to return true if the table
is smaller than the viewport height) that area is painted in the table background color
as defined by the ui, not in the color of table as set in code - that is it's schweinchenrosa,
not orange. Happens if focused only (jdk1.6, didn't check the no longer supported 1.5)
On the other side of the coin, the renderer opaque implementation (both DefaultTablecellRenderer
and JRendererLabel - simple c&p) rely on its opaque parent to paint its own background
as expected and guaranteed. The reasoning is that if the parent is opaque and has the
same background color as the child, then the child need not fill the background - it's
already must be done by the parent.
So, I'm veeery reluctant to change that implementation. Shortly before a release it's
a high risk that I overlook side-effects, JRendererLabel by default is used as rendering
component across all collection components. Taking that risk to cover up for core bugs
is ... hmm ...
I would suggest you file a bug in Sun's bug parade: you can use the left-side of the example
with a core JTable and instead of the JXTable as the right component take anything that's
focusable (as the error shows only on a focused table, the difference might give a hint
where/how exactly the misbehaviour happens).
As to your context - you distribute a tweaked version of SwingX anyway, right? - change
the isOpaque implementation and see how far it holds, I sure can be convinced by evidence
And by masses: start a discussion in the forum, drum up support and pressure <g>
I tend to change this to a task - revisit the implications of changing the implementation
to bare returning the property - and postpone to after 1.6 release.