On Fri, Sep 24, 2010 at 1:06 AM, Tim Ellison <t.p.elli...@gmail.com> wrote:
> On 24/Sep/2010 05:28, Robert Muir wrote: > > On Fri, Sep 24, 2010 at 12:10 AM, Tim Ellison <t.p.elli...@gmail.com> > wrote: > >> Thanks. Seems strange since it could obviously produce some 'unusual' > >> results. In this case, computing a hashCode, it likely doesn't matter > >> if the result is a bogus string. > >> > >> > > Do you have an example where the result would be unusual for a filename? > > I'm not thinking it would be unusual for being interpreted as file path > (e.g. it won't introduce a '/' or anything like that) but that the > result would not be the lowercase equivalent in the locale that the user > created the filename. > > but case-sensitive filenames (such as windows) don't use locale-dependent comparisons? they implement locale-independent case-folding. for example if i have a file "σ.txt", I cannot create "ς.txt". (I just tried) Both of these files are already in lowercase. The interesting question is: how does hashCode() relate? Because a hashcode based upon String.toLowerCase(Locale.ENGLISH) would return different hashcodes for these two filenames, but with UCharacter.foldCase(), it would be the same. -- Robert Muir rcm...@gmail.com
