According to the comment in JDK-8176490 the regression was introduced with JDK-8169589. And JDK-8169589 stats that this bug was fixed in 8u121 (among other).
But I am not able to reproduce the JDK-8176490 issue with WindowDeadlockTest [1] and 8u121 on macOS 10.12.3. But the test hangs with 8u152 b01 [2]. My question is: Is the upcoming Java 8 public release (planned for 10 April 2017) affected by JDK-8176490? We have thousands of customers who are using macOS so this could be a killer for us. Thanks Reto [1] http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/ [2] https://jdk8.java.net/download.html > On 27/03/2017 17:24, Alexander Zvegintsev wrote:> > Looks fine to me too. > > Thanks, > Alexander. > > On 27/03/2017 08:35, dmitry markov wrote: > > Thank you, Sergey! > > Looking for the second +1 from someone else. > > > > Thank you in advance, > > Dmitry > > On 24/03/2017 21:01, Sergey Bylokhov wrote: > >> Looks fine. > >> > >>> Hi Sergey, > >>> Thank you for the review. > >>> > >>> Actually deliverMoveResizeEvent() is always called once a window is > >>> displayed. If the window is created using max W/H of the screen, the > >>> function will be invoked and isZoomed field will contain the correct > >>> value. I have just checked that. > >>> > >>> Thanks, > >>> Dmitry > >>>> On 23 Mar 2017, at 16:36, Sergey Bylokhov > >>>> <sergey.bylok...@oracle.com> wrote: > >>>> > >>>> Hi, Dmitry. > >>>> Can you please check that the fix does not break the situation when > >>>> the frame is created using max W/H of the screen. In this case the > >>>> old zoom logic return true, is it possible that the new logic will > >>>> return false since deliverMoveResizeEvent > >>>> will not be called? > >>>> > >>>>> > >>>>> Hello, > >>>>> > >>>>> Could you review a fix for jdk9, please? > >>>>> > >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176490 > >>>>> webrev: > http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/ > >>>>> > >>>>> Problem description: > >>>>> On OSX AppKit thread and EDT or main application thread might be > >>>>> blocked when a child window is displayed and its parent is hidden > >>>>> at the same time. AppKit thread performs windows ordering caused > >>>>> by displaying of the child window. It retrieves child windows for > >>>>> the parent window and tries to acquire the monitor inside > >>>>> Window.getOwnedWindows_NoClientCode(). However the monitor > is > >>>>> already owned by EDT/main application thread which executes > >>>>> setVisible(false) on the parent window. That thread hangs on > >>>>> invocation of CWrapper.NSWindow.isZoomed() since the function > must > >>>>> be executed on AppKit thread. > >>>>> > >>>>> Fix: > >>>>> Add a new field isZoomed to CPlatformWindow class. The field will > >>>>> contain information about current zoom state for the window. The > >>>>> method deliverMoveResizeEvent() will update the new field using > >>>>> data from the platform. The invocations of > >>>>> CWrapper.NSWindow.isZoomed() in CPlatformWindow should be > replaced > >>>>> with isZoomed field. > >>>>> > >>>>> Note: I ran JCK tests on the build with fix and did not observe > >>>>> any new problems. > >>>>> > >>>>> Thanks, > >>>>> Dmitry > >
