That is perfect. +1.
--
best regards,
Anthony
On 2/27/2014 7:01 PM, Petr Pchelko wrote:
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.
