<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/23/23 1:06 PM, Archie Cobbs wrote:<br>
</div>
<blockquote type="cite" cite="mid:CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com">
<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" 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>
<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" 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>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>
<p><br>
</p>
<blockquote type="cite" cite="mid:CANSoFxum7aFO=DKOmYbE49i_HWs=+xHgGYo0L79agF3fBXrhrQ@mail.gmail.com">
<div dir="ltr">
<div>
<div class="gmail_quote">
<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>
</blockquote>
</body>
</html>