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

Anthony Petrov anthony.petrov at oracle.com
Thu Jul 10 21:43:05 UTC 2014


Hi Alexey,

I skimmed through the changes and they look fine to me. +1.

--
best regards,
Anthony

On 7/10/2014 7:59 PM, Alexey Ivanov wrote:
> 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.


More information about the awt-dev mailing list