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

[Jonathan Gibbons]

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.

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


>
> Admittedly I haven't really checked to see whether this would work but 
> a simple idea would be for the compiler to maintain e.g. a 
> Map<JavaFileObject, ClassSymbol> , then after writing out a classfile, 
> it adds the corresponding entry, OR finds that one already exists and 
> emits an error that the two ClassSymbol's have clashing output files.
>
> You would maintain separate mappings for classfiles, header files, and 
> source files.
>>
>>      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.

-- Jon


> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230223/9109e53c/attachment-0001.htm>