<Swing Dev> <AWT Dev> [9] Review request for JDK-8039383: NPE when changing Windows Theme
Sergey Bylokhov
Sergey.Bylokhov at oracle.com
Tue Jun 10 00:22:33 UTC 2014
On 6/10/14 2:18 AM, Phil Race wrote:
> I filed https://bugs.openjdk.java.net/browse/JDK-8046391
Looks like this is not a regression and duplicate of JDK-8042590
>
> -phil.
>
> On 6/9/2014 2:38 PM, Phil Race wrote:
>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Best regards, Sergey.
More information about the swing-dev
mailing list