RepaintManager and Dirty Reads

The first rule of Swing programming is to always interact with Swing components in the Event Dispatch Thread (EDT, for short).nbsp; Swing is single-threaded (as a lot of UInbsp;toolkits are) and as such it can only makes guarantees about the state of Swing components when interacted with properly on the EDT.nbsp; Some Swing methods are thread-safe, such as JComponent.repaint.nbsp; Recently, I discovered that RepaintManager, the class that handles Swing painting (used by JComponent.repaint), can access a JComponent#039;s state off of the EDT. The Problem Here#039;s what happened. My company, to ensure that we do not violate the Swing prime directive, uses an aspect to interleave EDT checking code in our internal builds.nbsp; During one of our latest builds, we started seeing threading violations reported.nbsp; At first, we thought it was the new look and feel we were using doing something untoward, but it was simply calling JComponent.repaint() from an animation thread.nbsp; Digging into the internals of the RepaintManager, I found the following: JComponent.repaint calls RepaintManager.addDirtyRegion. RepaintManager.addDirtyRegion calls into the private implementation RepaintManager.addDirtyRegion0. RepaintManager.addDirtyRegion0 calls JComponent methods without ensuring the calls happen on the EDT. getWidth() getHeight() getParent() isVisible() The following class demonst...

Date: January, 19 2011
Url: http://www.java.net/blog/kschaefe/archive/2011/01/11/repaintmanager-and-dirty-reads

Others News