<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2/22/23 10:59 AM, Archie Cobbs
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr">On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons
          <<a href="mailto:jonathan.gibbons@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">jonathan.gibbons@oracle.com</a>>
          wrote:</div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>On 2/22/23 8:06 AM, Archie Cobbs wrote:
              <blockquote type="cite"><br>
                <div>Add a new option <span style="font-family:monospace">-Xlint:fileclash</span>
                  that enables checking for clashes (e.g., at the <span style="font-family:monospace">JavacFileSystemManager</span>
                  layer).
                  <ol>
                  </ol>
                </div>
              </blockquote>
              <p>That would likely either be a partial solution, or an
                expensive one for a complete solution when taking
                separate compilation into account.<br>
              </p>
            </div>
          </blockquote>
          <div>I was thinking separate compilation would definitely not
            be supported (too complicated).</div>
          <div><br>
          </div>
          <div>Given that assumption, would it necessarily be only a
            partial fix?</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, it would be a partial fix, because by your own assumption,
      it would not cover some important cases.</p>
    <p>Also, the problem of file system issues is more than just
      case-clash class names; on Windows, you cannot (or used not to be
      able) to write files like CON, NUL, etc. (I haven't checked
      Windows to see if there are still issues there.)<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Admittedly I haven't really checked to see whether this
            would work but a simple idea would be for the compiler to
            maintain e.g. a <span style="font-family:monospace">Map<JavaFileObject,
              ClassSymbol></span> , then after writing out a
            classfile, it adds the corresponding entry, OR finds that
            one already exists and emits an error that the two <span style="font-family:monospace">ClassSymbol</span>'s have
            clashing output files.<br>
          </div>
          <div><br>
          </div>
          <div>You would maintain separate mappings for classfiles,
            header files, and source files.<br>
          </div>
          <div><span class="gmail-im">
              <blockquote type="cite">
                <div>
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px 0.8ex;border-left:1px solid
                    rgb(204,204,204);padding-left:1ex">
                    <ol>
                      <li>Add new compiler flags <span style="font-family:monospace">-dzip</span>, <span style="font-family:monospace">-szip</span>, <span style="font-family:monospace">-hzip</span>
                        (corresponding to <span style="font-family:monospace">-d</span>, <span style="font-family:monospace">-s</span>, <span style="font-family:monospace">-h</span>) that
                        specify ZIP files for output instead of
                        directories</li>
                    </ol>
                  </blockquote>
                </div>
              </blockquote>
            </span>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <p>I would recommend using the existing options, and just
                allow those options to specify a zip file, and then open
                the file with `zipfs`.   That being said, updating zip
                files by "overwriting" existing entries comes with its
                own set of problems.</p>
            </blockquote>
            <p>Yep.. for efficiency you'd probably need to do some
              gymnastics, e.g., have a staging directory, and then at
              the very end of the compilation write out a new ZIP file
              using merge sort with the original (if any).<br>
            </p>
          </div>
        </div>
      </div>
    </blockquote>
    <p>If anyone were to pursue this, I would recommend that it be done
      at least 99.99% in a separate implementation of 
      `java.nio.file.FileSystem`, and not directly in javac itself. 
      Such a FileSystem could be used without changing javac at all when
      invoking javac through its API (i.e.
      `javax.tools.JavaCompiler.getTask`), or with minimal change to
      command-line javac to specify the use of that file system.</p>
    <p>-- Jon<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CANSoFxuoNpo9mn9E5krdzBRmKkqidyN_nSX3R=7Tb0c6efUHng@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>-Archie<br>
          </div>
        </div>
        <br>
        -- <br>
        <div dir="ltr" class="gmail_signature">Archie L. Cobbs<br>
        </div>
      </div>
    </blockquote>
  </body>
</html>