Case-insensitive file systems and output file clashes - survey

[Archie Cobbs]

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?

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

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230222/90af75cb/attachment.htm>