<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi all,<br>
    <br>
    The changes look fine to me.<br>
    <br>
    <div class="moz-cite-prefix">On 4/26/2016 3:49 PM, Philip Race
      wrote:<br>
    </div>
    <blockquote cite="mid:571F63E3.8080908@oracle.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      > In applications one may need to know the reason why focus is
      requested<br>
      <br>
      I do not mean why should apps want to *know* the cause.<br>
      <br>
      I am asking why apps should be able to *specify* the cause as<br>
      proposed by this change.<br>
    </blockquote>
    <br>
    Currently an app, implementing a custom Component, may not even
    *know* the cause why focus is requested to the Component. Opening
    the methods lets the app override them at least.<br>
    <br>
    At the moment I don't have a real request in mind for this API. But
    the API indeed adds some more flexibility to focus management. For
    instance:<br>
    <br>
    - An app can know from which direction focus has been traversed to a
    custom component.<br>
    - An app can block focus request by mouse click preventing window
    activation (and for example, postpone it).<br>
    <br>
    Regards,<br>
    Anton.<br>
    <br>
    <blockquote cite="mid:571F63E3.8080908@oracle.com" type="cite"> <br>
      Being "symmetric" is not a sufficient reason.<br>
      <br>
      -phil.<br>
      <br>
      On 4/26/16, 12:27 AM, Semyon Sadetsky wrote:
      <blockquote cite="mid:571F1869.1040004@oracle.com" type="cite">
        <meta content="text/html; charset=utf-8"
          http-equiv="Content-Type">
        On 4/25/2016 10:33 PM, Phil Race wrote:<br>
        <blockquote cite="mid:571E711D.1060505@oracle.com" type="cite">
          <meta content="text/html; charset=utf-8"
            http-equiv="Content-Type">
          <div class="moz-cite-prefix">You will need to convince me of
            the appropriateness of opening these methods.<br>
            It seems to me that are for the focus system, not for
            applications.<br>
            <br>
            Why should an application be allowed to say "I would like
            component X" to<br>
            receive focus and tell it the reason is a mouse event" when
            in fact it is nothing of the kind.<br>
          </div>
        </blockquote>
        This is a continuation of the 8080395. I think it would be
        mostly interesting for framework developers not for
        applications.<br>
        In applications one may need to know the reason why focus is
        requested to the component before the focus is set to it.<br>
        As I heard from Anton (that was his task initially) opening the
        cause was requested by some client, but, unfortunately, I don't
        have any references.<br>
        <br>
        --Semyon<br>
        <blockquote cite="mid:571E711D.1060505@oracle.com" type="cite">
          <div class="moz-cite-prefix"> <br>
            I would like to hear from others if they see a valid use
            case and that there are no<br>
            down-sides to mis-use.<br>
            <br>
            -phil.<br>
            <br>
            On 04/19/2016 02:30 AM, Semyon Sadetsky wrote:<br>
          </div>
          <blockquote cite="mid:5715FABE.7050109@oracle.com" type="cite">
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            Hello, <br>
            <br>
            Please review fix for JDK9:<br>
            <br>
            bug: <a moz-do-not-send="true"
              class="moz-txt-link-freetext"
              href="https://bugs.openjdk.java.net/browse/JDK-8154434">https://bugs.openjdk.java.net/browse/JDK-8154434</a><br>
            webrev: <a moz-do-not-send="true"
              class="moz-txt-link-freetext"
              href="http://cr.openjdk.java.net/%7Essadetsky/8154434/webrev.00/">http://cr.openjdk.java.net/~ssadetsky/8154434/webrev.00/</a><br>
            <br>
            To support the new FocusEvent cause concept introduced by
            JDK-8080395 the next package-private methods of the
            java.awt.Component class are opened in the fix:<br>
            <br>
            boolean requestFocus(FocusEvent.Cause cause)  -> public
            void requestFocus(FocusEvent.Cause cause)
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            <br>
            <br>
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            boolean requestFocus(boolean temporary, FocusEvent.Cause
            cause) -> protected boolean requestFocus(boolean
            temporary, FocusEvent.Cause cause)<br>
            <br>
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            boolean requestFocusInWindow(FocusEvent.Cause cause) ->
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            public boolean requestFocusInWindow(FocusEvent.Cause cause)<br>
            <br>
            The methods are changed to be symmetric with the focus
            request methods of the same class which do not accept the
            cause parameter.<br>
            The method requestFocus(FocusEvent.Cause cause) was changed
            to return no value similarly to the requestFocus() because
            the returning boolean true cannot guarantee the focus gain.<br>
            <br>
            --Semyon<br>
            <br>
            <br>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
    </blockquote>
    <br>
  </body>
</html>