<Swing Dev> [9] Review request for 8046031: UI of Java Web Start app isn't updated when changing Windows theme

Semyon Sadetsky semyon.sadetsky at oracle.com
Mon Apr 25 17:56:45 UTC 2016



On 4/25/2016 5:58 PM, Sergey Bylokhov wrote:
> 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.
I see 4 at least:

             this.themeActive = new 
TriggerDesktopProperty("win.xpstyle.themeActive");
             this.dllName     = new 
TriggerDesktopProperty("win.xpstyle.dllName");
             this.colorName   = new 
TriggerDesktopProperty("win.xpstyle.colorName");
             this.sizeName    = new 
TriggerDesktopProperty("win.xpstyle.sizeName");

--Semyon
>
>> 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
>>>>
>>>
>>>
>>
>
>




More information about the swing-dev mailing list