A quick note to say: thanks for the detailed description and analysis of your problem. I realize that this blog entry exists mostly to highlight the underlying bug in the JDK, but after some serious deliberation on our part at Glazed Lists, we’ve decided to implement a work around for the problem as best we can. Here are the gory details of our “best-effort” workaround:

The code has been changed so that TableComparatorChooser watches for changes in the UI delegate of the JTableHeader. When a change is detected, it attempts to re-wrap the NEW default renderer for the JTableHeader, if a new renderer has replaced the one TableComparatorChooser installed.

BUT, the issue is that we cannot *always* coerce the WindowsTableHeaderUI into updating the default renderer of the JTableHeader. (It turns out this code in WindowsTableHeaderUI.installUI(…) will only do it when switching TO XP mode, switching to classic mode will leave our renderer in situ):

if (XPStyle.getXP() != null) {
originalHeaderRenderer = header.getDefaultRenderer();
if (originalHeaderRenderer instanceof UIResource) {
header.setDefaultRenderer(new XPDefaultRenderer());
}
}

So, our contingency is that if the delegate renderer throws a RuntimeException, we discard it and fall back to DefaultTableCellRenderer. Blech. In this case, Table Headers won’t render like the underlying UI delegate normally would, but we feel it’s marginally better than an endless stream of NullPointerExceptions from WindowsTableHeaderUI$XPDefaultRenderer that destroys your application.

C’est la vie.

you have my vote to have this bug fixed (by sun), if that means anything.

BR,
~A