<Swing Dev> <AWT Dev> [7u-dev] Review request for JDK-8046559: NPE when changing Windows theme

[Alexey Ivanov]

Hi AWT, Swing teams,

Could you please review the backport of JDK-8046559 to jdk7:
     bug: https://bugs.openjdk.java.net/browse/JDK-8046559
     webrev: http://cr.openjdk.java.net/~aivanov/8046559/jdk7/webrev.00/


Changes between jdk9 and jdk7:

I replaced labmda expression in WToolkit.java with anonymous class.
It is the only change from the previous webrev:
http://mail.openjdk.java.net/pipermail/awt-dev/2014-July/008147.html
http://mail.openjdk.java.net/pipermail/swing-dev/2014-July/003657.html


Latest jdk9 webrev: 
http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/


The information is below is copied from jdk9 review for the sake of 
completeness.


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 accessed via XPStyle and ThemeReader. When the 
theme is switched to a classic one, theme handles become unavailable, 
and theme data cannot be accessed any more. The change in theme is 
posted to EDT; at the same time, the UI often needs to repaint before 
the theme change is completely handled in Swing. This leads to NPE and 
InternalError as the code tries to access the data that has become 
unavailable.

The fix:
Windows desktop properties are updated right on Windows Toolkit thread, 
and the value of "win.xpstyle.themeActive" is stored in 
ThemeReader.xpStyleEnabled field. PropertyChangeEvents for desktop 
properties are delivered either synchronously on EDT or asynchronously 
via DesktopPropertyChangeSupport, as it used to be.

Getters in XPStyle class check for null values and return dummy defaults 
if ThemeReader returned null. SkinPainters also check whether theming is 
still available before asking ThemeReader to paint.

Access to XPStyle.xp instance is blocked as soon as user switches 
themes. The object will be cleaned when the corresponding 
PropertyChangeEvent is handled by Swing.


This new version of the fix addresses issues found with the initial 
submission of JDK-8039383 fix:
   - JDK-8046239: Build failure in 9-client on all non-Windows platforms
   - JDK-8046391: Hang displaying JFileChooser with Windows L&F

See also 
http://mail.openjdk.java.net/pipermail/awt-dev/2014-June/007975.html
and http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/


Regression test:
No regression test is provided due to its complexity. Whether 
NullPointerException or InternalError are thrown depends on the order of 
event handling, sometimes exceptions do not occur when changing theme of 
visual styles enabled theme to a classic theme.

I included regression test for hang in JFileChooser, JDK-8046391.


Thank you,
Alexey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20140710/ada1e43d/attachment.html>