United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6508168 NullPointerException while updateUI() in MouseListener of JTable header.
6508168 : NullPointerException while updateUI() in MouseListener of JTable header.

Details
Type:
Bug
Submit Date:
2006-12-27
Status:
Closed
Updated Date:
2010-04-04
Project Name:
JDK
Resolved Date:
2007-01-08
Component:
client-libs
OS:
windows_xp
Sub-Component:
javax.swing
CPU:
x86
Priority:
P4
Resolution:
Duplicate
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
JDK-4178930 - Swing models need pre- and post-listeners

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
NullPointerException when executing JTable header updateUI() from MouseListener of this header.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. javac Test.java
2. java Test
3. Click on table header by left mouse button two times.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
nothing
ACTUAL -
NullPointerException

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at javax.swing.plaf.basic.BasicTableHeaderUI$MouseInputHandler.mouseClicked(Unknown Source)
	at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
	at java.awt.Component.processMouseEvent(Unknown Source)
	at javax.swing.JComponent.processMouseEvent(Unknown Source)
	at java.awt.Component.processEvent(Unknown Source)
	at java.awt.Container.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Window.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import javax.swing.table.DefaultTableModel;
import javax.swing.table.TableModel;

public class TestTable {
	public static void main(String[] args) {
		TableModel tm = new DefaultTableModel(3, 3);
		final JTable table = new JTable(tm);
		table.getTableHeader().addMouseListener(new MouseAdapter() {
			public void mouseClicked(MouseEvent event) {
				table.getTableHeader().updateUI();
			}
		});
		JScrollPane pan = new JScrollPane(table);
		JFrame fr = new JFrame();
		fr.getContentPane().add(pan);
		fr.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		fr.setSize(300, 200);
		fr.setVisible(true);
	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use repaint() instead of updateUI().

Comments
EVALUATION

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.
2007-01-08


Hardware and Software, Engineered to Work Together