<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I have updated the webrev [1], the difference is that now in case of
    error, a message is printed to warn the user,<br>
    <br>
    Thanks,<br>
    Vicente<br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~vromero/8216529/webrev.01/">http://cr.openjdk.java.net/~vromero/8216529/webrev.01/</a><br>
    <br>
    <div class="moz-cite-prefix">On 1/14/19 5:59 PM, Vicente Romero
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a50cb9ba-ca19-bc84-b093-d3a738467a12@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <br>
      <br>
      <div class="moz-cite-prefix">On 1/14/19 4:20 PM, Jonathan Gibbons
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        Do you mean the trimming done by jtreg?   That will obviously
        only happen if the crash happens in the context of a test.<br>
      </blockquote>
      <br>
      no I saw that issue for bugs breaking the JDK build and I saw that
      the output was incomplete<br>
      <br>
      <blockquote type="cite"
        cite="mid:716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com"> <br>
        As a general solution, if you can't write the file, you could
        write the non-file options, and the first N files, to the
        console, for some suitable N. That being said, if you're just
        printing argv, you don't easily have the analysis of file vs
        non-file options, so it may just come down to print the first N
        args, for a different, bigger N.<br>
      </blockquote>
      <br>
      I tend to believe that the general case in which this will be most
      useful will be cases with a large number of parameters, so I tend
      to think that it should be better to generate no output rather
      than generate an incomplete output. But I could be convinced
      otherwise :)<br>
      <br>
      <blockquote type="cite"
        cite="mid:716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com"> <br>
        -- Jon<br>
      </blockquote>
      <br>
      Vicente<br>
      <br>
      <blockquote type="cite"
        cite="mid:716f0216-8f78-b539-dfa9-4fffea69ff97@oracle.com"> <br>
        <br>
        <br>
        <div class="moz-cite-prefix">On 01/14/2019 12:03 PM, Vicente
          Romero wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:0b4d139c-7b74-7158-8be1-feb3f27dade7@oracle.com">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          Hi Liam,<br>
          <br>
          <div class="moz-cite-prefix">On 1/14/19 2:38 PM, Jonathan
            Gibbons wrote:<br>
          </div>
          <blockquote type="cite"
            cite="mid:eb6603c5-480d-d944-1c73-9d939cd8fa40@oracle.com">
            <meta http-equiv="Content-Type" content="text/html;
              charset=UTF-8">
            <p>The intent is the crash report should contain the path of
              the file, and the file should be in "@-file" format, to
              make it easier to rerun the compilation using the file
              with `javac @javac.<date>.args`.   If an error
              occurs when writing to the file, the info could be written
              to the console, but note that there could be a huge amount
              of output, depending how many files are specified on the
              command-line.</p>
          </blockquote>
          <br>
          right, what Jon says. I decided not to write to the console
          because if the output is huge, most of it will be lost as it
          will be trimmed thus reducing the usefulness of it.<br>
          <br>
          <blockquote type="cite"
            cite="mid:eb6603c5-480d-d944-1c73-9d939cd8fa40@oracle.com">
            <p>-- Jon<br>
            </p>
          </blockquote>
          <br>
          Vicente<br>
          <br>
          <blockquote type="cite"
            cite="mid:eb6603c5-480d-d944-1c73-9d939cd8fa40@oracle.com">
            <p> </p>
            <div class="moz-cite-prefix">On 1/14/19 11:22 AM, Liam
              Miller-Cushon wrote:<br>
            </div>
            <blockquote type="cite"
cite="mid:CAL4Qsgub5dPRc2rPdpDyQBEMskqdTUHY8RO2VVfBiwYBZ1Q52w@mail.gmail.com">
              <meta http-equiv="content-type" content="text/html;
                charset=UTF-8">
              <div dir="ltr">Hi Vicente,
                <div><br>
                </div>
                <div>This looks useful.</div>
                <div><br>
                </div>
                <div>Did you consider printing the args to stderr
                  instead of writing them to a file, maybe as part of
                  msg.bug? If I'm reading the patch correctly it
                  currently uses a file `javac.<date>.args` in the
                  directory javac is running from, which users won't
                  necessarily know about to include in crash reports,
                  and which won't succeed if javac doesn't have
                  permissions to create files in the working directory.</div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr">On Mon, Jan 14, 2019 at 10:51 AM Vicente
                  Romero <<a href="mailto:vicente.romero@oracle.com"
                    moz-do-not-send="true">vicente.romero@oracle.com</a>>
                  wrote:<br>
                </div>
                <blockquote class="gmail_quote" style="margin:0px
                  0px&#xA; 0px&#xA; 0.8ex;border-left:1px
                  solid&#xA;&#xA; rgb(204,204,204);padding-left:1ex">Please
                  review the fix for enhancement [1] at [2]. The idea of
                  this <br>
                  enhancement is to print out to a file the arguments
                  passed to javac is <br>
                  there is a fatal error or if a hidden option is passed
                  to the compiler. <br>
                  This could be very helpful to reproduce some bugs
                  reported by users.<br>
                  <br>
                  Thanks,<br>
                  Vicente<br>
                  <br>
                  PS, thanks to Jon for offline feedback an suggestions<br>
                  <br>
                  [1] <a
                    href="https://bugs.openjdk.java.net/browse/JDK-8216529"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8216529</a><br>
                  [2] <a
                    href="http://cr.openjdk.java.net/%7Evromero/8216529/webrev.00/"
                    rel="noreferrer" target="_blank"
                    moz-do-not-send="true">http://cr.openjdk.java.net/~vromero/8216529/webrev.00/</a><br>
                </blockquote>
              </div>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>