On 22.04.16 19:29, Semyon Sadetsky wrote:
On 4/21/2016 10:46 PM, Sergey Bylokhov wrote:
Hi, Semyon.
As far as I understand from the bug description, the method
DesktopProperty.updateUI() is called on the different EDT? Does it
mean that we share the same DesktopProperty object across different
Appcontext? (if not then probably we can skip the usage of Appcontext
and change the field to non-static)?
No, we do not share the same DesktopProperty object, but it would be odd
to expect that there is only one DesktopProperty per app context.
Why it is odd? This code is called in the "propertyChange()" which
executes on some EDT, each EDT is bound already to some specific
Appcontext. Otherwise we should store all data inside this class per
appcontext(since we don't do this I assume that we store this object per
Appcontext). Plus I see it is used only in the WinLookAndFeel and the
l&f itself is stored per appcontext also.
Putting the flag into the app scope protects from scheduling events
recursively
If the Appcontext is necessary, then we should not use interned string
as a key, I suggest to use the simple new Object(), so it will not be
accessible outside of this class.
This is a public field. Accessing it outside the class shouldn't be an
issue.
I overlooked that it is public in my first email. Why? If it is not used
outside of this class it should be private. Also the interned string
will provide a way to access this data even if "com/sun/java/swing"
package will be inaccessible. So it is better to use private key.
--Semyon
On 21.04.16 16:56, Alexandr Scherbatiy wrote:
The fix looks good to me.
Thanks,
Alexandr.
On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8046031
webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
Under the Windoew LnF when the native Windows theme is changed some
java frames remains unchanged if there are several application
contexts. The thing is the DesktopProperty#updatePending flag that
prevents to run more then one UI update operation is shared between
different applications contexts while they may be updated with the
property change concurrently from different EDT threads so they may
loose the update.
To avoid this mutual interference the updatePending is moved from the
global to the application context scope.
The test would require to write native code so the issue is labeled
noreg-hard.
--Semyon
--
Best regards, Sergey.
