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

Ethan McCue ethan at mccue.dev
Mon Feb 20 16:39:09 UTC 2023


To throw a unicode wrench in the mix.

    class cafe\u0301 {

    }

    class caf\u00e9 {

    }

    public class Main {
        public static void main(String[] args) {
            var a = new cafe\u0301();
            var b = new caf\u00e9();

            System.out.println(a);
            System.out.println(b);
        }
    }

I seem to only get one café.class file out in the end.

On Mon, Feb 20, 2023 at 11:15 AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

>
>
> On Mon, Feb 20, 2023 at 7:27 AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> > Also note that what exactly
>> > case-insensitive means depends on your
>> > choice of Locale (see also this link
>> <https://stackoverflow.com/q/8899929/263801>). That
>> > may or may not matter depending on the
>> > approach.
>>
>> 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
>>
>
> Nope...
>
> $ cat Décérébélé.java
> public class Décérébélé { }
> $ javac -d classes Décérébélé.java
> $ ls classes/
> Décérébélé.class
>
> I am suggesting this behaviour instead.
>>
>> ---
>> $ javac -d classes {a,b}/*.java
>> $ ls classes/
>> FOO$1.class Foo$2.class
>> ---
>>
>> 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.
>>
>> Would that not work as a solution for both of our scenarios?
>>
>
> 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".
>
> Your idea *can* be done in a compatible way for local classes. Here's a
> sample patch
> <https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8287885>.
> This would be a limited, tactical change that doesn't solve the whole
> problem but addresses the ASCII-only narrow case in the bug.
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/72070741/attachment.htm>


More information about the compiler-dev mailing list