<div dir="ltr"><div dir="ltr">On Thu, Feb 23, 2023 at 7:25 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>
    <p>On 2/23/23 1:06 PM, Archie Cobbs wrote:
    </p>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>
          <div dir="ltr">On Thu, Feb 23, 2023 at 1:33 PM Jonathan
            Gibbons <<a href="mailto:jonathan.gibbons@oracle.com" target="_blank">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>
                <p>On 2/22/23 10:59 AM, Archie Cobbs wrote: </p>
                <blockquote type="cite">
                  <div dir="ltr">
                    <div dir="ltr">On Wed, Feb 22, 2023 at 12:12 PM
                      Jonathan Gibbons <<a href="mailto:jonathan.gibbons@oracle.com" target="_blank">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>Yes, it would be a partial fix, because by your own
                  assumption, it would not cover some important cases.</p>
              </div>
            </blockquote>
            <div>Well I guess I meant, would it be "partial" in some way
              besides the fact that separate compilations are not taken
              into account.</div>
            <div><br>
            </div>
            <div>Digressing a bit, I'm not sure I agree that not
              supporting separate compilations makes it partial. Isn't a
              "compilation" the extent of the unit of work that a
              compiler is being asked to do? Asking it to solve problems
              that span multiple compilations seems out of scope. Or
              maybe I'm misunderstanding what you mean by "compilation".<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Compiling against precompiled class files is expecting javac to
      solve a problem spanning multiple compilations. :-)</p>
    <p>That being said, I agree it is a reasonable expectation that any
      one compilation should not write the same physical file more than
      once, and so it might be reasonable to have a possibly always-on
      diagnostic if that situation is detected, perhaps even an error. 
      Like the (separate) zip file discussion, this could be handled
      inside a custom file manager.  The challenge may be in specifying
      the behavior correctly, and not over-promising in the command-line
      help or man page. But if you stick to something like the following
      in the man page, you may be OK:</p>
    <p>   An error will be reported if any file is written more than
      once during a compilation. This may occur in the following
      situations: list-of-known-situations</p></div></blockquote><div>I've put together a draft PR demonstrating this idea: <a href="https://github.com/openjdk/jdk/pull/12754">https://github.com/openjdk/jdk/pull/12754</a></div><br><div>It wasn't really feasible to NOT do this within the existing JavacFileManager/BaseFileManager framework. But the changes are fairly well contained and it works for all three output file types: class files, source files, and native header files.<br></div><div><br></div><div>I hid this behind a new "extended" javac flag <span style="font-family:monospace">--detect-output-file-clashes</span> instead of adding it as a new lint option... somehow it didn't really seem like a "lint" thing.<br></div><div><div><br></div><div>Please let me know what you think.</div><div><br></div></div><div>-Archie<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>