<div dir="ltr"><div dir="ltr">On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons <<a href="mailto:jonathan.gibbons@oracle.com">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><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>-Archie<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>