Hi Dmitry, I have used this version for testing: java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
This is the latest official public Java 8 release from Oracle. All our customers obtain Java from https://java.com/ Thanks Reto Von: dmitry markov <dmitry.mar...@oracle.com> An: Reto Merz <reto.m...@abacus.ch> Kopie: 'Alexander Zvegintsev' <alexander.zvegint...@oracle.com>, 'Sergey Bylokhov' <sergey.bylok...@oracle.com>, 'awt-dev' <awt-dev@openjdk.java.net> Gesendet: 28.03.2017 20:41 Betreff: Re: <AWT Dev> [9] Review request for 8176490: [macosx] Sometimes NSWindow.isZoomed hangs Hi Reto, JDK-8169589 was integrated into 8u121-b31. What build of 8u121 did you use for testing? Also JDK-8169589 was included into 8u131 (upcoming April release). I am afraid we do not have enough time to integrate the fix for JDK-8176490 into 8u131. Thanks, Dmitry On 28/03/2017 14:26, Reto Merz wrote: 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://urldefense.proofpoint.com/v2/url?u=https-3A__jdk8.java.net_download.html&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=oXUXbFfbTpz-M7ef_niHcXp1OK4CwY9URWfDWqeeGSc&m=p4_83q4GHe2-oaP5YEKC2rwF3we54NSigzxwUypoMEw&s=RlKgriUXqduWXEILzrpT8a8serl1myFuoXjj2IsxLrg&e= 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
