<AWT Dev> <Swing Dev> [9] Review request for JDK-8039383: NPE when changing Windows Theme

[Alexey Ivanov]

Hi Anthony,

Thank you for your review.

Yes, user code can install a property change listener... It was my 
concern too, that's why I explicitly noted about this.

Do you have any suggestion how this situation can be handled?
Is it a general rule that all desktop property change listeners must be 
called on EDT?


Thanks,
Alexey.

On 18.04.2014 16:02, Anthony Petrov wrote:
> Hi Alexey,
>
>> With this change, property "win.xpstyle.themeActive" change is fired 
>> on the toolkit thread
>
> Is it possible to install a change listener for this property from 
> user code, and hence eventually allow executing some user code on the 
> toolkit thread with your fix?
>
> -- 
> best regards,
> Anthony
>
> On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
>> Hello Swing and AWT teams,
>>
>> Could you please review the fix for jdk9:
>>      bug: https://bugs.openjdk.java.net/browse/JDK-8039383
>>      webrev: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/
>>
>> Problem description:
>> When changing Windows themes from a theme with visual styles (Windows
>> Aero or Windows Basic) to a classic one, NullPointerException could be
>> thrown from Swing code during component tree validation, or
>> InternalError could be thrown during component painting.
>>
>> Root cause:
>> Windows theme data are "cached" in XPStyle object. When the theme is
>> switched to a classic one, HTHEME handle becomes unavailable and data
>> cannot be accessed from the theme any more. The change in theme in
>> posted to EDT via invokeLater. At the same time, the UI needs to repaint
>> itself as soon as Windows changed the theme, and paint code is often
>> called before the theme change is handled in Java. This leads to NPE and
>> InternalError as the code tries to access the data that has become
>> unavailable.
>>
>> The fix:
>> Update "win.xpstyle.themeActive" desktop property and invalidate the
>> cached XPStyle as soon as windowsSettingChange() is called from native
>> code. Thus when Swing code needs to access theme data, it will see no
>> theme is available and will fallback to classic painting.
>>
>> Note: Before the fix, PropertyChangeEvents for desktop properties in
>> Windows were fired on the Event Dispatch Thread. With this change,
>> property "win.xpstyle.themeActive" change is fired on the toolkit
>> thread; all other properties are changed on the EDT as before.
>>
>>
>> Regards,
>> Alexey.