NullPointerException at javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting

I've been battling the NPE below for some months now; it cannot be reproduced on demand, but occurs often enough. My biggest problem is that I can't seem to figure out what is going wrong (using jre1.5.0_5, code below the exception) and have to resort to this uninviting post, hoping someone can can shed a light here.

The exeption is:

java.lang.NullPointerException
        at javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting(BasicTableUI.java:882)
        at javax.swing.plaf.basic.BasicTableUI$Handler.adjustFocusAndSelection(BasicTableUI.java:942)
        at javax.swing.plaf.basic.BasicTableUI$Handler.mousePressed(BasicTableUI.java:897)
        at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:222)
        at java.awt.Component.processMouseEvent(Component.java:5485)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3126)
        at org.tbee.swing.table.JTableForEdit.processMouseEvent(JTableForEdit.java:244)
        at java.awt.Component.processEvent(Component.java:5253)
        at java.awt.Container.processEvent(Container.java:1966)
        at java.awt.Component.dispatchEventImpl(Component.java:3955)
        at java.awt.Container.dispatchEventImpl(Container.java:2024)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
        at java.awt.Container.dispatchEventImpl(Container.java:2010)
        at java.awt.Window.dispatchEventImpl(Window.java:1774)
        at java.awt.Component.dispatchEvent(Component.java:3803)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        at org.tbee.swing.StandardComponentPopupMenu.dispatchEvent(StandardComponentPopupMenu.java:98)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Now, after unpacking the src.zip in the jdk1.5.0_05 and looking at the BasicTableUI.java line 882 it turns out to be the method declaration:

882:    protected void setValueIsAdjusting(boolean flag) {
            table.getSelectionModel().setValueIsAdjusting(flag);
            table.getColumnModel().getSelectionModel().
                    setValueIsAdjusting(flag);
        }

But looking at the body, I expect either getSelectionModel being the culprit.

Now to finding the reason why: I first assume it is something I do in handling the mouse event. In the stack trace I find two pieces of code I made (both are from a swing library I maintain):

org.tbee.swing.StandardComponentPopupMenu.dispatchEvent

and

org.tbee.swing.table.JTableForEdit.processMouseEvent

StandardComponentPopupMenu is a custom class to get standard popup menu's on several components, for example "copy" on text components or "select all rows" on tables. It is hooked into the system event queue (with thanks to Santhosh Kumar):

Toolkit.getDefaultToolkit().getSystemEventQueue().push(getStandardComponentPopupMenu());

The line in the exception shows that the logic of the component has not been executed yet, since it first processes the event normally:

      protected void dispatchEvent(AWTEvent event)
      {
            // handle regularly
98:            super.dispatchEvent(event);


JTableForEdit is a JTable extend which tries to make data entry go more like it does in MSAccess. The method in the trace does nothing more than detect if the last action was a keystroke or a mouse thing.

      protected void processMouseEvent(MouseEvent e)
      {
            // remember keystroke
            iLastKeyStroke = null;
                  
            // done
            super.processMouseEvent(e);
      }

Both pieces of code do not give any reason why this would NPE. Unfortunately both classes are very relevant to the application, so I cannot deactivate them to see if the NPE doesn't occur any more.

LVL 2
tbeernotAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
objectsConnect With a Mentor Commented:
yes, many moons ago we produced a patched swing jar that added an assert to methods for tracking down these sorts of problems. aspects may well be able to handle doing similiar.

Sorry I can't give you anything more concrete, but tracking down gui bugs that are not reproduceable can be a real pain and I'm not aware of any silver bullets.
0
 
Mayank SAssociate Director - Product EngineeringCommented:
>> jdk1.5.0_05

I am not sure how stable that is - I would use 1.5.0_06
0
 
objectsCommented:
make sure you aren't making *any* calls in your code that update the gui from a thread other than the event dispatch thread.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
tbeernotAuthor Commented:
@objects: this might very well be possible, it is a rather large and multithreading ERP application, so slipping "the thread" could be present somewhere. What thread crossing could cause this NPE?
0
 
objectsCommented:
Swing is single threaded such that any calls that affect the gui need to be made from the EDT.
Breaking this rule can result in indeterminite behaviour.

http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html
0
 
tbeernotAuthor Commented:
I know, but such a generic statement does not give much handle on the problem. I need a way to find the culprit that causes the NPE to be set up.
0
 
objectsCommented:
there is no easy way sorry. Adding asserts anywhere in your code that updates the gui to check your on the correct thread would be a good start.
In your case anything updating the table would seem a good place to start.

But the problem could be caused by something different, if you can create a small example that demonstrates it it may be worth submitting to Sun as a bug.
0
 
tbeernotAuthor Commented:
I'll settle for finding the cause :-)

I've been thinking about using AspectJ to handle some of my swing issues for some time now. It does seem that the "crossconcern" that any swing method call should be made by the EDT, is something that falls into the aspect category. I'm curious if AspectJ can catch swing calls... I could then dump a stack trace.
0
 
tbeernotAuthor Commented:
AspectJ (ADTJ) cause my Eclipse 3.1.2 to hang big time. Had to reinstall Eclipse twice (luckily that is easy). So that path was abanoned. I found a class which does a similar check: ThreadCheckingRepaintManager. Hooked in into the application and now it's wait-and-see.
0
 
tbeernotAuthor Commented:
Autch.

It is unbelievable how methods under water can call Swing. It's the do-this, fire event and the listener calls swing execution path. So a "calculateTotal" on a bean may trigger swing. I've got some serious cleaning to do...
0
 
tbeernotAuthor Commented:
Currently I'm running with a special swing hook-in to see if the problem still occurs and of course it was vacation time. I'll try and see next week if the problem is gone and if yes accept "Date: 06/19/2006 11:54PM PDT"
0
All Courses

From novice to tech pro — start learning today.