<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">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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<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></div></blockquote><div>Yes, but in those cases an error is generated, right? In contrast of course the problems that stem from case-insensitive filesystems are "silent" errors.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div><span>
<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></div></blockquote><div>That's a neat approach.</div><div><br></div><div>The idea of a javac flag like <span style="font-family:monospace">--use-filesystem-impl com.foobar.MyFileSystem</span> is something that could be useful in its own right.<br></div></div><br clear="all"></div><div>-Archie</div><div><br></div><div>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>