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

[Archie Cobbs]

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".


> 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/7911368a/attachment.htm>