After an offline discussion with Sergey I've got a new version of he fix: http://cr.openjdk.java.net/~pchelko/9/8032960/webrev.02/
Looks like previously the DesktopPropertyChangeSupport was intended to be called only on some EDT. But now we have to call it on a Toolkit thread, so I've removed the short path, so it now always posts an events and never calls listeners directly. With best regards. Petr. On 27.02.2014, at 18:18, Petr Pchelko <[email protected]> wrote: > 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. >>> >
