harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)
Date Fri, 24 Sep 2010 05:49:48 GMT
On 24/Sep/2010 06:13, Robert Muir wrote:
> On Fri, Sep 24, 2010 at 1:06 AM, Tim Ellison <t.p.ellison@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.ellison@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.

Ah ok, I didn't realize that windows did that.

> 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.

System.out.println(new File("σ.txt").hashCode());
System.out.println(new File("ς.txt").hashCode());

prints out

889962580
890776533

on both Harmony and the RI.

Regards,
Tim



Mime
View raw message