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.iva...@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.iva...@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.iva...@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.
