Hello, Alexey. Looks OK to me too.
With best regards. Petr. > On Jul 11, 2014, at 1:43 AM, Anthony Petrov <[email protected]> wrote: > > 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.
