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:06:05 GMT
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.

> In this case the Unicode standard gives a nice background (in fact,
> filenames are given as the example): see Unicode 5.18, caseless matching:
> http://www.unicode.org/versions/Unicode5.2.0/ch05.pdf
> 
> side note: toLowerCase(ENGLISH) isn't exactly the case folding algorithm
> they describe, thats UCharacter.foldCase(String, ...). But its close and the
> idea is the same.

We also lowercase the hostnames passed into SocketPermissions.  I'm
guessing we should do those as English too for the same reasons.  Today
we lowercase them with the default locale which may give unexpected results.

Regards,
Tim

Mime
View raw message