<div dir="auto">Hello Archie,<div dir="auto"><br></div><div dir="auto">Thank you for your response.</div><div dir="auto"><br></div><div dir="auto">> I can reproduce this on my Macbook</div><div dir="auto">> (which has case-preserving but </div><div dir="auto">> case-insensitive filesystem by default)</div><div dir="auto">> as well</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div>> As the example above shows, just fixing<div dir="auto">> the problem for inner class names would</div><div dir="auto">> only be a partial fix.</div><div dir="auto"><br></div><div dir="auto">Great catch. Yes, this problem extends far outside of local classes, so we may need a better solution than what I proposed here ---> <a href="https://bugs.openjdk.org/browse/JDK-8287885?focusedCommentId=14506844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14506844">https://bugs.openjdk.org/browse/JDK-8287885?focusedCommentId=14506844&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14506844</a></div><div dir="auto"><br></div><div dir="auto">> And of course, this is not just a problem</div><div dir="auto">> for the compiler, but also the runtime...</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">> One could imagine adding a flag like </div><div dir="auto">> "-dzip classes.zip" which would write the</div><div dir="auto">> classes to a ZIP file instead of the</div><div dir="auto">> filesystem.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">> So just brainstorming here... what would</div><div dir="auto">> it take to fix this?</div><div dir="auto"><div dir="auto"><br></div><div dir="auto">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).</div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">> So fixing this is do-able but not trivial</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thank you again for your time and insight!</div><div dir="auto">David Alayachew</div></div>