Could someone take another look at my submitted bug regarding class names?

[David Alayachew]

Hello Archie,

Thank you for your response.

> I can reproduce this on my Macbook
> (which has case-preserving but
> case-insensitive filesystem by default)
> as well

Thank you very much for pointing this out. I figured this behaviour would
exist on other OS' but didn't have a Mac to test. Knowing now that this
exists on 2 major OS', especially as a default setting, really makes this
bug even more painful in my eyes.

> As the example above shows, just fixing
> the problem for inner class names would
> only be a partial fix.

Great catch. Yes, this problem extends far outside of local classes, so we
may need a better solution than what I proposed here --->
https://bugs.openjdk.org/browse/JDK-8287885?focusedCommentId=14506844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14506844

> And of course, this is not just a problem
> for the compiler, but also the runtime...

And not only that, but (echoing my bug submission) if you have more than 2
classes whose names are equal aside from casing, you still only get one
error. Meaning, if you make 3 classes whose names differ only in casing,
your program will fail at the first failed attempt to find the class. You
fix the name for class 2, recompile all classes with no warnings, rerun,
and then get hit with the same error for class 3, whose filename is still
equal except for casing.

> One could imagine adding a flag like
> "-dzip classes.zip" which would write the
> classes to a ZIP file instead of the
> filesystem.

I see what you're getting at. Regardless of the OS, .zip files always
respect case, and therefore, you could bypass this problem for all OS' by
simply interfacing with a file format that can't run into this problem.

One potential benefit that this solution brings (though I am very ignorant
about it) is that Java has many tools that allow it to easily interface
with .zip files, so a lot of the infrastructure may already be there to
make this change. Again, I speak from ignorance here, so this could just be
woefully wrong.

> So just brainstorming here... what would
> it take to fix this?

As I see it, the entire problem boils down to the compiler trying to be
case-sensitive, while the file storage location (the underlying OS) is
case-insensitive (but with a name that retains its original casing).

Maybe I am naive, but why not add a signifier/suffix to the resulting
.class file name to differentiate? Java already does this. Going back to my
local classes example, if 2 local classes have the exact same name (where
even the cases are the same), javac will call them Abc.java and Abc$1.java,
or something like that. The point is, appending a signifier at the end is
apparently good enough for the compiler to be able to tell which class to
load when we run the compiled code. Would that not be an effective solution
here too? Of course, I don't know the internal logic that allows us to see
Abc$1.java and know that we have the right class.

> So fixing this is do-able but not trivial

I see what you mean. One thing that may be helpful as an intermediate goal
would be to emit a warning/error on compile when running into this. At
least then, we can minimize the impact of developers unexpectedly running
into this during runtime. In the meantime, a more complex and long term
solution can be developed.

Thank you again for your time and insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230219/84db3e92/attachment.htm>