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

Archie Cobbs archie.cobbs at gmail.com
Mon Feb 20 16:14:12 UTC 2023


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/6e0fd989/attachment-0001.htm>


More information about the compiler-dev mailing list