Case-insensitive file systems and output file clashes - survey

[Archie Cobbs]

A few bugs I've looked at recently relate to two compiler output files
"clashing" in the sense that they end up mapping to the same actual file in
the file system.

Two of these are due to case-insensitive filesystems:

JDK-8287885 <https://bugs.openjdk.org/browse/JDK-8287885> - Local classes
cause ClassLoader error if the type names are similar but not same
JDK-8296656 <https://bugs.openjdk.org/browse/JDK-8296656> -
java.lang.NoClassDefFoundError exception on running fully legitimate code

I submitted a PR for the first bug above, but it's a gross combination of
being an ugly hack and also not really solving the real problem (I'm going
to withdraw it).

Side note: another related bug, though this one is not the filesystem's
fault (it's due to inherent clashing in the JNI specification) but would be
affected by some of the ideas mentioned below:

JDK-7016187 <https://bugs.openjdk.org/browse/JDK-7016187> - `javac -h`
could generate conflict .h for inner class and class name with '_'

Survey question: What do you think should be done about this
case-insensitive filesystem problem?

   1. Nothing. Resolve all such bugs "Not an Issue" with the comment "Go
   away! Case-insensitive filesystems are not supported!"
   2. Add a new option -Xlint:fileclash that enables checking for clashes
   (e.g., at the JavacFileSystemManager layer).
   3. Same as #2 but instead of requiring a lint flag, test the filesystem
   at startup and proactively enable the warning only if case-insensitive
   4. Add new compiler flags -dzip, -szip, -hzip (corresponding to -d, -s,
   -h) that specify ZIP files for output instead of directories
   5. Your other clever idea...

Thanks,
-Archie

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