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

[Jonathan Gibbons]

On 2/19/23 8:45 PM, Archie Cobbs wrote:
> On Sun, Feb 19, 2023 at 9:04 PM David Alayachew 
> <davidalayachew at gmail.com> wrote:
>
>     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?
>
>
> That would work for synthetic inner classes. It still doesn't solve 
> the larger problem though.
>
>     > So fixing this is do-able but not trivial
>
>     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.
>
> 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.

Even that is not enough; the files may be written by different 
compilations. The file manager would potentially read the contents of 
every file before overwriting it, to decide whether to generate a message.

-- Jon



>
> 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.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230220/9a8c1131/attachment-0001.htm>