Hello, Anthony. You were right, in case the Toolkit thread has an AppContext we should invoke the updateProperties through invokeLater as the DesktopPropertyChangeSupport could invoke a propertyChangeListener directly.
Please see the updated fix here: http://cr.openjdk.java.net/~pchelko/9/8032960/webrev.01/ I've also added an automatic test, but it's quite complicated. With best regards. Petr. On 20.02.2014, at 12:45, Anthony Petrov <[email protected]> wrote: > Hi Petr, > > The fire...() method is now invoked on the Toolkit thread, and I see that the > Toolkit.DesktopPropertyChangeSupport.firePropertyChange() will fire the event > on the current thread if the toolkit thread belongs to the current app > context. > > The question is: are we 100% sure that on MS Windows the AWT Toolkit thread > *never* belongs to a user app context? Even if we're running in an unusual > threading mode (like the one for FX where we combine the EDT and the FX > toolkit thread)? > > If this is so, meaning that we always only postEvent() from the > T.DPCS.fire...() method on Windows, then I'm fine with the fix. > > -- > best regards, > Anthony > > On 2/19/2014 3:29 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-8032960 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/8032960/webrev.00/ >> >> The problem: >> The Toolkit thread does not have an AppContext so we can't use >> EventQueue.invokeLater on it. >> >> The solution: >> Remove invokeLater. This is safe, because the updateProperties is thread >> safe. The result of this call is a post of a PropertyChangeEvent for each >> AppContext in the application. >> >> The test: >> Hard to create, because we can't synthesize the WM_SETTINGCHANGE event. >> >> Thank you. >> With best regards. Petr. >>
