[External] : Re: Case-insensitive file systems and output file clashes - survey

[Jonathan Gibbons]

On 2/23/23 1:06 PM, Archie Cobbs wrote:
> On Thu, Feb 23, 2023 at 1:33 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     On 2/22/23 10:59 AM, Archie Cobbs wrote:
>
>>     On Wed, Feb 22, 2023 at 12:12 PM Jonathan Gibbons
>>     <jonathan.gibbons at oracle.com> wrote:
>>
>>         On 2/22/23 8:06 AM, Archie Cobbs wrote:
>>>
>>>         Add a new option -Xlint:fileclash that enables checking for
>>>         clashes (e.g., at the JavacFileSystemManager layer).
>>>
>>         That would likely either be a partial solution, or an
>>         expensive one for a complete solution when taking separate
>>         compilation into account.
>>
>>     I was thinking separate compilation would definitely not be
>>     supported (too complicated).
>>
>>     Given that assumption, would it necessarily be only a partial fix?
>
>     Yes, it would be a partial fix, because by your own assumption, it
>     would not cover some important cases.
>
> Well I guess I meant, would it be "partial" in some way besides the 
> fact that separate compilations are not taken into account.
>
> 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".

Compiling against precompiled class files is expecting javac to solve a 
problem spanning multiple compilations. :-)

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:

    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


>     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.)
>
> 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.
>
>
>>>          1. Add new compiler flags -dzip, -szip, -hzip
>>>             (corresponding to -d, -s, -h) that specify ZIP files for
>>>             output instead of directories
>>>
>>         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.
>>
>>     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).
>>
>     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.
>
> That's a neat approach.
>
> The idea of a javac flag like --use-filesystem-impl 
> com.foobar.MyFileSystem is something that could be useful in its own 
> right.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230223/78bdcd91/attachment-0001.htm>