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

Phil Race philip.race at oracle.com
Mon Jun 9 21:38:57 UTC 2014 

Hi,
So the repo now builds but when I run SwingSet2 on Windows and select 
the Win L&F and
try to bring up JFileChooser the whole app hangs. Looks like the same 
deadlock/hang that we
saw on 7u60 (I think). I assumed this was to be the fix that addressed 
the NPE *and*
did not hang the app.

"AWT-EventQueue-0" #12 prio=6 os_prio=0 tid=0x0d5d8c00 nid=0x208c 
runnable [0x0d
c1d000]
    java.lang.Thread.State: RUNNABLE
         at sun.awt.windows.ThemeReader.setWindowTheme(Native Method)
         at sun.awt.windows.ThemeReader.getThemeImpl(ThemeReader.java:93)
         at sun.awt.windows.ThemeReader.getTheme(ThemeReader.java:113)
         at sun.awt.windows.ThemeReader.getEnum(ThemeReader.java:189)
         at 
com.sun.java.swing.plaf.windows.XPStyle.getTypeEnumName(XPStyle.java:
149)
         at 
com.sun.java.swing.plaf.windows.XPStyle.getBorder(XPStyle.java:275)
         - locked <0x1021fa90> (a com.sun.java.swing.plaf.windows.XPStyle)
         at 
com.sun.java.swing.plaf.windows.WindowsToolBarUI.getRolloverBorder(Wi
ndowsToolBarUI.java:94)
         at 
javax.swing.plaf.basic.BasicToolBarUI.setBorderToRollover(BasicToolBa
rUI.java:692)
         at 
javax.swing.plaf.basic.BasicToolBarUI$Handler.componentAdded(BasicToo
lBarUI.java:1131)
         at java.awt.Container.processContainerEvent(Container.java:2270)
         at java.awt.Container.processEvent(Container.java:2241)
         at java.awt.Component.dispatchEventImpl(Component.java:4892)
         at java.awt.Container.dispatchEventImpl(Container.java:2302)
         at java.awt.Component.dispatchEvent(Component.java:4714)
         at java.awt.Container.addImpl(Container.java:1146)
         - locked <0x158a6570> (a java.awt.Component$AWTTreeLock)
         at javax.swing.JToolBar.addImpl(JToolBar.java:581)
         at java.awt.Container.add(Container.java:425)
         at sun.swing.WindowsPlacesBar.<init>(WindowsPlacesBar.java:136)
         at 
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.updateUseShellFo
lder(WindowsFileChooserUI.java:508)
         at 
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installComponent
s(WindowsFileChooserUI.java:213)
         at 
javax.swing.plaf.basic.BasicFileChooserUI.installUI(BasicFileChooserU
I.java:173)
         at 
com.sun.java.swing.plaf.windows.WindowsFileChooserUI.installUI(Window
sFileChooserUI.java:150)
         at javax.swing.JComponent.setUI(JComponent.java:665)
         at javax.swing.JFileChooser.updateUI(JFileChooser.java:1837)
         at javax.swing.JFileChooser.setup(JFileChooser.java:372)
         at javax.swing.JFileChooser.<init>(JFileChooser.java:344)
         at javax.swing.JFileChooser.<init>(JFileChooser.java:297)
         at FileChooserDemo.createFileChooser(FileChooserDemo.java:129)
         at FileChooserDemo$2.actionPerformed(FileChooserDemo.java:148)
         at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:20
23)
         at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.jav
a:2347)
         at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel
.java:403)
         at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:260
)
         at 
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonL
istener.java:252)
         at java.awt.Component.processMouseEvent(Component.java:6536)
         at javax.swing.JComponent.processMouseEvent(JComponent.java:3323)
         at java.awt.Component.processEvent(Component.java:6301)
         at java.awt.Container.processEvent(Container.java:2244)
         at java.awt.Component.dispatchEventImpl(Component.java:4892)
         at java.awt.Container.dispatchEventImpl(Container.java:2302)
         at java.awt.Component.dispatchEvent(Component.java:4714)
         at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4908
)
         at 
java.awt.LightweightDispatcher.processMouseEvent(Container.java:4543)
         at 
java.awt.LightweightDispatcher.dispatchEvent(Container.java:4472)
         at java.awt.Container.dispatchEventImpl(Container.java:2288)
         at java.awt.Window.dispatchEventImpl(Window.java:2739)
         at java.awt.Component.dispatchEvent(Component.java:4714)
         at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
         at java.awt.EventQueue.access$500(EventQueue.java:97)
         at java.awt.EventQueue$3.run(EventQueue.java:702)
         at java.awt.EventQueue$3.run(EventQueue.java:696)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
main.java:75)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
main.java:86)
         at java.awt.EventQueue$4.run(EventQueue.java:724)
         at java.awt.EventQueue$4.run(EventQueue.java:722)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDo
main.java:75)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
         at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
ad.java:201)
         at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
java:116)
         at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.java:105)
         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)

         at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

"AWT-Windows" #10 daemon prio=6 os_prio=0 tid=0x0d707c00 nid=0x1854 
waiting on c
ondition [0x0be6e000]
    java.lang.Thread.State: WAITING (parking)
         at sun.misc.Unsafe.park(Native Method)
         - parking to wait for  <0x1576d430> (a 
java.util.concurrent.locks.Reentr
antReadWriteLock$NonfairSync)
         at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInt
errupt(AbstractQueuedSynchronizer.java:836)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(A
bstractQueuedSynchronizer.java:870)
         at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Abstrac
tQueuedSynchronizer.java:1199)
         at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(Reen
trantReadWriteLock.java:942)
         at sun.awt.windows.ThemeReader.flush(ThemeReader.java:67)
         at 
sun.awt.windows.WDesktopProperties.getProperties(WDesktopProperties.j
ava:244)
         - locked <0x158595d0> (a sun.awt.windows.WDesktopProperties)
         at sun.awt.windows.WToolkit.getWProps(WToolkit.java:966)
         - locked <0x15859538> (a sun.awt.windows.WToolkit)
         at sun.awt.windows.WToolkit.windowsSettingChange(WToolkit.java:938)
         at sun.awt.windows.WToolkit.eventLoop(Native Method)
         at sun.awt.windows.WToolkit.run(WToolkit.java:305)
         at java.lang.Thread.run(Thread.java:745)

-phil.
On 6/9/2014 6:17 AM, Alexey Ivanov wrote:
> Hi Phil,
>
> My bad, I didn't pay due attention to other platforms because I 
> modified files specific to Windows and Windows LaF. Since Windows LaF 
> is not available at other platforms, I was sure these classes are 
> compiled only for Windows. My assumption proved to be wrong. In 
> future, I will always build all the platforms even if the changes are 
> platform-specific.
>
>
> Anthony, Petr,
>
> Could you please review my fix for build failure in another thread?
>
> I am really sorry about build failure. I won't make it happen again.
>
>
> Thanks,
> Alexey.
>
> On 06.06.2014 21:54, Phil Race wrote:
>> I filed P1 bug https://bugs.openjdk.java.net/browse/JDK-8046239
>>
>> You really should at least build on other platforms and you can use 
>> JPRT for that ..
>> Testing would be good too ..
>>
>> -phil.
>>
>> On 6/6/2014 10:48 AM, Phil Race wrote:
>>> ahem, this is a "bad fix". It has broken all non-windows builds 
>>> because shared code
>>> is now referencing WToolkit and ThemeReader. Please back out this 
>>> fix ASAP ..
>>>
>>> -phil.
>>>
>>> On 6/6/2014 7:03 AM, Anthony Petrov wrote:
>>>> You're welcome.
>>>>
>>>> -- 
>>>> best regards,
>>>> Anthony
>>>>
>>>> On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
>>>>> Hi Anthony, Petr,
>>>>>
>>>>> Thank you for reviewing my fix.
>>>>>
>>>>> Regards,
>>>>> Alexey.
>>>>>
>>>>>
>>>>> On 06.06.2014 15:19, Anthony Petrov wrote:
>>>>>> +1
>>>>>>
>>>>>> -- 
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 6/6/2014 3:20 PM, Petr Pchelko wrote:
>>>>>>> Hello, Alexey.
>>>>>>>
>>>>>>> The final version still looks good.
>>>>>>>
>>>>>>> With best regards. Petr.
>>>>>>>
>>>>>>> On 06 июня 2014 г., at 15:02, Alexey Ivanov
>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hi Anthony, Petr, AWT and Swing teams,
>>>>>>>>
>>>>>>>> I've addressed Anthony's and Petr's comments in the updated 
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.04/
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Alexey.
>>>>>>>>
>>>>>>>> On 06.06.2014 12:16, Alexey Ivanov wrote:
>>>>>>>>> Hi Anthony,
>>>>>>>>>
>>>>>>>>> Thank you for your review.
>>>>>>>>>
>>>>>>>>> I've removed synchronized modifier from updateProperties() method
>>>>>>>>> which protected access to wprops field. Now this field is 
>>>>>>>>> accessed
>>>>>>>>> from synchronized methods lazilyInitWProps() and getWProps();
>>>>>>>>> setDesktopProperty also has proper synchronization - that was my
>>>>>>>>> reasoning for removing synchronized.
>>>>>>>>>
>>>>>>>>> But you're right, it was not the right decision as the update 
>>>>>>>>> loop
>>>>>>>>> now could execute simultaneously which is undesirable. I'll put
>>>>>>>>> synchronized modifier to updateProperties() method.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey.
>>>>>>>>>
>>>>>>>>> On 06.06.2014 1:07, Anthony Petrov wrote:
>>>>>>>>>> Hi Alexey,
>>>>>>>>>>
>>>>>>>>>> In WToolkit.java you're removing the synchronized modifier from
>>>>>>>>>> the private updateProperties() method. And it looks like the
>>>>>>>>>> method itself does allow for calling from multiple threads. 
>>>>>>>>>> So I'm
>>>>>>>>>> concerned about the lack of synchronization in this method. Was
>>>>>>>>>> the removal intentional? How is the method supposed to work now
>>>>>>>>>> when called from multiple threads?
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>> On 6/5/2014 12:16 PM, Petr Pchelko wrote:
>>>>>>>>>>> Thank you for clarifications, I've been most interested in #2
>>>>>>>>>>> obviously.
>>>>>>>>>>>
>>>>>>>>>>> The fix looks good to me.
>>>>>>>>>>>
>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>
>>>>>>>>>>> On 05 июня 2014 г., at 11:57, Alexey Ivanov
>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello Petr,
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you for your comments.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Sure, I'll remove the comment before the change set is 
>>>>>>>>>>>> pushed.
>>>>>>>>>>>> 2. No, I didn't try stub XPStyle object. First of all, UI
>>>>>>>>>>>> delegates decide what painting method to use depending on
>>>>>>>>>>>> whether XPStyle.getXP() returns null or not. If 
>>>>>>>>>>>> XPStyle.getXP()
>>>>>>>>>>>> always returns non-null value, we'll have re-implement all UI
>>>>>>>>>>>> delegates for Windows plaf, and I believe it would result in
>>>>>>>>>>>> larger changeset. Additionally, some classes fallback to
>>>>>>>>>>>> inherited behavior where XPStyle.getXP() is not available.
>>>>>>>>>>>> Another reason is that UI delegates cache Skins: those objects
>>>>>>>>>>>> shouldn't paint where theming is unavailable.
>>>>>>>>>>>> 3. No, I haven't filed any bugs yet. I'll file all the issues
>>>>>>>>>>>> I've found in the nearest future.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>
>>>>>>>>>>>> On 05.06.2014 11:08, Petr Pchelko wrote:
>>>>>>>>>>>>> Hello, Alexey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A couple of comments:
>>>>>>>>>>>>> 1. ThemeReader:64 - I suggest to remove that comment as it 
>>>>>>>>>>>>> does
>>>>>>>>>>>>> not add any value. The variable name is self explanatory.
>>>>>>>>>>>>> 2. XPStyle - did you try providing a stub XPStyle object
>>>>>>>>>>>>> instead of changing many of it's methods? Do I understand
>>>>>>>>>>>>> correctly that this
>>>>>>>>>>>>> is not possible because XPstyle is cached in many place is 
>>>>>>>>>>>>> our
>>>>>>>>>>>>> code?
>>>>>>>>>>>>> 3. In offline discussion you've mentioned that you've found
>>>>>>>>>>>>> another related issue. Did you have a chance to file a bug
>>>>>>>>>>>>> about it?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>> With best regards. Petr.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05 июня 2014 г., at 10:35, Alexey Ivanov
>>>>>>>>>>>>> <alexey.ivanov at oracle.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~aivanov/8039383/jdk9/webrev.03/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What has changed since version .02?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> During additional testing, I found another scenario where 
>>>>>>>>>>>>>> NPE
>>>>>>>>>>>>>> was thrown. So the new version adds more checks to prevent
>>>>>>>>>>>>>> access to XPStyle and ThemeReader where Windows visual 
>>>>>>>>>>>>>> styles
>>>>>>>>>>>>>> become unavailable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As in previous version, getters in XPStyle class check for
>>>>>>>>>>>>>> null values and return dummy defaults if ThemeReader 
>>>>>>>>>>>>>> returned
>>>>>>>>>>>>>> null. Skin painters also check whether theming is still
>>>>>>>>>>>>>> available before asking ThemeReader to paint.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Access to XPStyle.xp instance is blocked as soon as user
>>>>>>>>>>>>>> switched themes. The object will be cleaned when the
>>>>>>>>>>>>>> corresponding PropertyChangeEvent is handled by Swing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 06.05.2014 12:14, Alexey Ivanov wrote:
>>>>>>>>>>>>>>> Hi AWT and Swing teams,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you please review the updated fix:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.02/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What has changed since version .01?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The issue was still reproducible with the .01 version of 
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> fix, however it was harder to reproduce.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So in version .02 I added checks for null where 
>>>>>>>>>>>>>>> possible. If
>>>>>>>>>>>>>>> theme becomes unavailable, a dummy value will be used; this
>>>>>>>>>>>>>>> way applications will be more stable. As soon as the theme
>>>>>>>>>>>>>>> change events are handled, the entire UI will update 
>>>>>>>>>>>>>>> properly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 24.04.2014 16:23, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>> Hi Anthony, AWT and Swing teams,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's the updated fix:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.01/ 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>>> In the new version of the fix, I use a new xpstyleEnabled
>>>>>>>>>>>>>>>> field of AtomicBoolean in WToolkit to track the current
>>>>>>>>>>>>>>>> value of "win.xpstyle.themeActive" desktop property. Its
>>>>>>>>>>>>>>>> value is updated in windowsSettingChange() and in
>>>>>>>>>>>>>>>> updateProperties().
>>>>>>>>>>>>>>>> XPStyle.getXP() checks its cached value in themeActive and
>>>>>>>>>>>>>>>> the current value in WToolkit; if the value changes, it
>>>>>>>>>>>>>>>> schedules updateAllUIs and invalidates the current style
>>>>>>>>>>>>>>>> right away, so that components would not access data from
>>>>>>>>>>>>>>>> the theme that became unavailable.
>>>>>>>>>>>>>>>> Two functions in ThemeReader also check this special field
>>>>>>>>>>>>>>>> from WToolkit which prevents throwing InternalError when
>>>>>>>>>>>>>>>> paint is called before theme change is fully handled.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Before updateAllUIs is invoked, it's possible that
>>>>>>>>>>>>>>>> application will paint with some values cached from the
>>>>>>>>>>>>>>>> previous theme. Usually it happens before "Theme change"
>>>>>>>>>>>>>>>> dialog disappears from the screen, at least I noticed 
>>>>>>>>>>>>>>>> no UI
>>>>>>>>>>>>>>>> glitches during normal theme change.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regression test:
>>>>>>>>>>>>>>>> No regression test is provided due to its complexity.
>>>>>>>>>>>>>>>> Additionally, 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>> Alexey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 18.04.2014 18:52, Anthony Petrov wrote:
>>>>>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, unfortunately I don't have any suggestions right now.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> As for allowing executing user code on the toolkit 
>>>>>>>>>>>>>>>>> thread,
>>>>>>>>>>>>>>>>> we can't accept such a fix. Sorry about that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -- 
>>>>>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/18/2014 6:48 PM, Alexey Ivanov wrote:
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

More information about the awt-dev mailing list