<div dir="ltr">To throw a unicode wrench in the mix.<br><br> class cafe\u0301 {<br><br> }<br><br> class caf\u00e9 {<br><br> }<br><br> public class Main {<br> public static void main(String[] args) {<br> var a = new cafe\u0301();<br> var b = new caf\u00e9();<br><br> System.out.println(a);<br> System.out.println(b);<br> }<br> }<br><br>I seem to only get one café.class file out in the end. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 20, 2023 at 11:15 AM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div><div dir="ltr" class="gmail_attr">On Mon, Feb 20, 2023 at 7:27 AM David Alayachew <<a href="mailto:davidalayachew@gmail.com" target="_blank">davidalayachew@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">> Also note that what exactly <div dir="auto">> case-insensitive means depends on your</div><div dir="auto">> choice of Locale (see also <a href="https://stackoverflow.com/q/8899929/263801" rel="noreferrer" target="_blank">this link</a>). That</div><div dir="auto">> may or may not matter depending on the</div><div dir="auto">> approach.</div><div dir="auto"><br></div><div dir="auto">Good catch, ty. From what I have read, it seems like java class names must be limited to a very small set of ASCII characters</div></div></blockquote><div><br></div><div>Nope...</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">$ cat Décérébélé.java <br>public class Décérébélé { }<br>$ javac -d classes Décérébélé.java <br>$ ls classes/<br>Décérébélé.class</span></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I am suggesting this behaviour instead.<div dir="auto"><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><div dir="auto">$ javac -d classes {a,b}/*.java</div><div dir="auto">$ ls classes/</div><div dir="auto">FOO$1.class Foo$2.class</div></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">Now, each class file is unique, regardless of OS casing. And if we were to open up these 2 class files, they wouldn't reference each other using Foo and FOO - they would use FOO$1 and Foo$2. That way, they know where exactly what .class file to reference, as there is only one match.</div></div><div dir="auto"><br></div><div dir="auto">Would that not work as a solution for both of our scenarios?</div></div></blockquote><div><br></div>Sorry I should have been clearer... yes your idea would solve the
problem, but at the expense of backward compatibility. That makes it a
non-starter. As Jon points out that would be "an incompatible change of seismic proportions".</div><div><br></div><div>Your idea *can* be done in a compatible way for local classes. <a href="https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8287885" target="_blank">Here's a sample patch</a>. This would be a limited, tactical change that doesn't solve the whole problem but addresses the ASCII-only narrow case in the bug.<br></div><div><br></div><div>-Archie<br></div><div><br></div>-- <br><div dir="ltr">Archie L. Cobbs<br></div></div>
</blockquote></div>