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

[David Alayachew]

Hello Archie,

Thank you for your response.

> 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, and even within that
set, there are more restrictions. Based on that, and the fact that class
names must match their created .class file names (with the exception of the
aforementioned suffixes/signifiers), I think we should be good for either
of our suggested solutions. Unless I misunderstand Locale and it's impacts?


> Even a warning is non-trivial. It's normal
> to overwrite existing class files, so you
> couldn't rely on checking whether the file
> already existed. The file manager would
> have to keep track of every class file that
> it has written out so it could detect when
> a clash occurs, or something like that.

Fair point. And furthermore, that tracking you are describing is likely
what would be needed if we want the compiler to be robust enough to handle
these valid class names without making a .zip file.

> That would work for synthetic inner
> classes. It still doesn't solve the larger
> problem though.

I'm not following.

To my understanding, $ is a valid character in Java class names and .class
filenames. It is also strongly discouraged for developers to intentionally
name their classes like that. Reason being that the compiler wants to use
that character for handling things like Abc$1.java like I mentioned before.

So, when we compile our classes using javac, the compiler checks for name
conflicts between all provided java classes (keeping in mind the casing and
how it plays with OS'), then generates a unique suffix for all
"conflicting" class names.

Then, you name each "conflicting" class name with their respective class
name + suffix, and then you literally put in Abc$1 as the explicit class
inside of the .class files. That way, during runtime, we know which class
is referencing which .class file, and vice versa.

Let's use your code as an example. You wrote the following execution.

---
$ javac -d classes {a,b}/*.java
$ ls classes/
Foo.class
---

As you showed previously, the above will fail at runtime because only one
.class file was generated.

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?

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