Here's what's happening:
Initially, the table header gets two listeners, which are notified in this order:
1) Listener installed by the UI
2) Listener installed by the developer
On the first mouse click, listener 1 is notified, followed by listener 2.
When listener 2 is notified, it calls updateUI() which removes the old UI and listener, and then installs a new UI and listener. Now the header again has two listeners, but in a different order:
1) Listener installed by the developer
2) Listener installed by the UI
The next mouse event causes this sequence of events:
- Listener 1 removes the UI and listener 2 and installs a new UI and listener.
- Listener 2, which is already in the queue to be notified, is notified.
- When Listener 2 is notified, it is in a state such that its associated UI has been removed. Hence the exception.
First and foremost, if the developer doesn't need to be updating the UI, they can solve this problem by simply removing the call to updateUI. If they need it, then they can work around the problem by removing and re-installing their listener after a UI change.
As far as Swing solving this problem, we have an RFE (4178930) that should allow this to be solved. This RFE aims to provide the ability to specify a listener's order, and will include making changes such that listener ordering is preserved with UI switches.