Bug - Fixed Store Manager exceptions still happen

[Veracity]

I got another exception managing my store. I thought I fixed all that - and I'm certainly not getting exceptions multiple times per day any more - by clearing the old sold item list, building and sorting the replacement, and then replacing the new list in bulk, rather than incrementally changing the list, item by item, allowing Swing to re-sort while it is being modified.

This time I actually recognize that "com.sun.java.forums.TableSorter" is a library class that we pulled in ourself, rather than it being built-in to Java. And, net.sourceforge.kolmafia.swingui.table.TransparentTable is all our own code.

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 0
	at com.sun.java.forums.TableSorter.modelIndex(TableSorter.java:276)
	at com.sun.java.forums.TableSorter.getValueAt(TableSorter.java:322)
	at javax.swing.JTable.getValueAt(JTable.java:2686)
	at javax.swing.JTable.prepareRenderer(JTable.java:5703)
	at net.sourceforge.kolmafia.swingui.table.TransparentTable.prepareRenderer(TransparentTable.java:64)
	at javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:2072)
	at javax.swing.plaf.basic.BasicTableUI.paintCells(BasicTableUI.java:1974)
	at javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:1770)
	at javax.swing.plaf.ComponentUI.update(ComponentUI.java:153)
	at javax.swing.JComponent.paintComponent(JComponent.java:752)
	at javax.swing.JComponent.paint(JComponent.java:1029)
	at javax.swing.JComponent.paintChildren(JComponent.java:862)
	at javax.swing.JComponent.paint(JComponent.java:1038)
	at javax.swing.JViewport.paint(JViewport.java:766)
	at javax.swing.JComponent._paintImmediately(JComponent.java:5098)
	at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:812)
	at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:714)
	at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:694)
	at javax.swing.RepaintManager.access$700(RepaintManager.java:41)
	at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1672)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:677)
	at java.awt.EventQueue.access$000(EventQueue.java:85)
	at java.awt.EventQueue$1.run(EventQueue.java:638)
	at java.awt.EventQueue$1.run(EventQueue.java:636)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:647)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

 

[roippi]

This was addressed with r11252. Swing is not thread-safe, so changes to the data model needed to happen on Swing's EDT - otherwise, multithreading issues cause exceptions like the above.