<Swing Dev> <AWT Dev> [7u-dev] Review request for JDK-8046559: NPE when changing Windows theme
Alexey Ivanov
alexey.ivanov at oracle.com
Thu Jul 10 15:59:41 UTC 2014
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>
More information about the swing-dev
mailing list