> We didn't change JComponent.repaint() to make it "no longer thread safe" > and I don't see why someone may think about it
The bug report https://netbeans.org/bugzilla/show_bug.cgi?id=192548 shows the stack: - With the latest changes to jdk7 and jdk6 update 22 it's no longer true due to repaint()'s call to getLocationOnScreen() which acquires AWT tree lock: java.awt.Component.getLocationOnScreen(Component.java:1995) javax.swing.SwingUtilities.convertPointToScreen(SwingUtilities.java:380) javax.swing.SwingUtilities.convertPoint(SwingUtilities.java:182) javax.swing.SwingUtilities.convertRectangle(SwingUtilities.java:219) javax.swing.RepaintManager.addDirtyRegion(RepaintManager.java:455) javax.swing.JComponent.repaint(JComponent.java:4791) java.awt.Component.repaint(Component.java:3264) This causes deadlocks. Even in JDK's code itself - the JEditorPane.PageLoader may get deadlocked in the same way. - I see that code path in the JDK7-ea but not in 6u23 or 6u25 (I don't have 6u22 installed). Neither version of JComponent#repaint() are documented to be thread-safe though, although this blog http://weblogs.java.net/blog/kschaefe/archive/2011/01/19/repaintmanager- and-dirty-reads says so based on http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html HTH, Walter.
