<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Reto,<br>
    <br>
    <a class="issue-link" data-issue-key="JDK-8169589"
      href="https://bugs.openjdk.java.net/browse/JDK-8169589"
      id="key-val" rel="4906561">JDK-8169589</a> was integrated into
    8u121-b31. What build of 8u121 did you use for testing?<br>
    <br>
    Also <a class="issue-link" data-issue-key="JDK-8169589"
      href="https://bugs.openjdk.java.net/browse/JDK-8169589"
      id="key-val" rel="4906561">JDK-8169589</a> was included into 8u131
    (upcoming April release). I am afraid we do not have enough time to
    integrate the fix for <a class="issue-link"
      data-issue-key="JDK-8176490"
      href="https://bugs.openjdk.java.net/browse/JDK-8176490"
      id="key-val" rel="4917944">JDK-8176490</a> into 8u131.<br>
    <br>
    Thanks,<br>
    Dmitry<br>
    <div class="moz-cite-prefix">On 28/03/2017 14:26, Reto Merz wrote:<br>
    </div>
    <blockquote
      cite="mid:67dcc394-849a-42e0-be7e-d58bfc7e5f59@abacus.ch"
      type="cite">
      <pre wrap="">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] <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/">http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/</a>
[2] <a class="moz-txt-link-freetext" href="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=">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=</a> 


</pre>
      <blockquote type="cite">
        <pre wrap="">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:
</pre>
        <blockquote type="cite">
          <pre wrap="">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:
</pre>
          <blockquote type="cite">
            <pre wrap="">Looks fine.

</pre>
            <blockquote type="cite">
              <pre wrap="">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
</pre>
              <blockquote type="cite">
                <pre wrap="">On 23 Mar 2017, at 16:36, Sergey Bylokhov
<a class="moz-txt-link-rfc2396E" href="mailto:Sergey.Bylokhov@oracle.com"><Sergey.Bylokhov@oracle.com></a> 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?

</pre>
                <blockquote type="cite">
                  <pre wrap="">
Hello,

Could you review a fix for jdk9, please?

    bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8176490">https://bugs.openjdk.java.net/browse/JDK-8176490</a>
    webrev:
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap=""><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/">http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/</a>
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">
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
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">is
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">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
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">must
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">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
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
        <pre wrap="">replaced
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">with isZoomed field.

Note: I ran JCK tests on the build with fix and did not observe
any new problems.

Thanks,
Dmitry
</pre>
                </blockquote>
              </blockquote>
            </blockquote>
          </blockquote>
          <pre wrap="">
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">

</pre>
    </blockquote>
    <br>
  </body>
</html>