On Mon, 1 Dec 2025 07:41:10 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> When a `JTable `using any objects of type `DefaultTableCellRenderer`, or >> subclasses, is serialized, >> the colors used to render cells in the JTable subsequent to the call to >> `writeObject()` >> are forced to the default colors for `DefaultTableCellRenderer`'s immediate >> base class, JLabel, causing the colors >> defined in the JTable (typically black on white) to be ignored. >> >> The problem seems to stem from a call to >> `installUI `in the `writeObject()` method of `JLabel`, >> `DefaultTableCellRenderer`'s base class. >> This causes the `setForeground` and `setBackground` methods to be invoked >> with specific colors, which turn out to be JLabel's defaults. >> Invoking these methods subsequently with parameters of null restores normal >> operation same as is explicitly done in `DefaultTableCellRenderer.updateUI()` >> https://github.com/openjdk/jdk/blob/195b36f90b789b64f4a0fc867c620935d609a455/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L159-L162 >> >> CI run is ok.. > > Prasanta Sadhukhan has updated the pull request incrementally with one > additional commit since the last revision: > > Rethrow Exception > > How/why does null restore the JTable-specified colors ? I don't see > > anything about null in the spec. And what have people been doing the last > > 25 years if serializing a JTable "broke" its rendering ? > > Specifying null would cause `unselectedForeground` and `unselectedBackground` > to be null > > > > so it will fallback to table assigned foreground and background color > So how do people know that ? Reading the source and trial and error don't count as ways to know. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28549#issuecomment-3643911298
