Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of rcmuir@gmail.com designates
 209.85.161.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=SgJYJiWMlyk42s4aAh5bF5ZCq584/4chPjgvBb9hcWbZLRIaKuoZ+0Y2l0uhB95RYD
         AmWNrEkyzNJyJrsFHTH9jPgJ29cRtUPnvkquFx4Nk4ym9LazhpZ/+5JbzYT9bLAA04tE
         BSJLQlgsLnLVYUhH5YpzMazD1+ybtDBZy/+NM=
MIME-Version: 1.0
In-Reply-To: <AANLkTimpEm+ZTC=esH0SR1yoiGO-bZMm=UytLL9R=ug9@mail.gmail.com>
References: <16508996.357041285200633873.JavaMail.jira@thor>
 <4C9ABC65.6000202@gmail.com>
 <AANLkTi=aoBjQxUAb_mT-bwJgQzTsXsN=7afu4Exiv8we@mail.gmail.com>
 <4C9C0E0B.6080703@gmail.com>
 <AANLkTin+i275fiJ_w9o8qt5Di8q4jKWBOiQVQEZd0rxX@mail.gmail.com>
 <4C9C24C1.6030809@gmail.com>
 <AANLkTi=nU6vfSj+0AfiwrC=1DaYGNkumqW7r0Dheyn82@mail.gmail.com>
 <4C9C31BD.2010504@gmail.com>
 <AANLkTimpEm+ZTC=esH0SR1yoiGO-bZMm=UytLL9R=ug9@mail.gmail.com>
From: Robert Muir <rcmuir@gmail.com>
Date: Fri, 24 Sep 2010 01:46:24 -0400
Message-ID: <AANLkTi=xHY04UbGwVvBUGc8r9NfN54Em8uzUfova=H=3@mail.gmail.com>
Subject: Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for
 supplementary characters (HARMONY-6649)
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=0016368e1f82544ccf0490fae759

--0016368e1f82544ccf0490fae759
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Sep 24, 2010 at 1:13 AM, Robert Muir <rcmuir@gmail.com> wrote:

>
> 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 "=CF=83.txt", I cannot create "=CF=82.txt". (I just tried)
> Both of these files are already in lowercase.
>
> The interesting question is: how does hashCode() relate? Because a hashco=
de
> based upon String.toLowerCase(Locale.ENGLISH) would return different
> hashcodes for these two filenames, but with UCharacter.foldCase(), it wou=
ld
> be the same.
>

i did more tests here against windows, and looking at the api link you
provided:
http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28%=
29

<http://download.oracle.com/javase/6/docs/api/java/io/File.html#hashCode%28=
%29>windows
appears to implement something closer to 'simple case folding':
http://icu-project.org/apiref/icu4j/com/ibm/icu/lang/UCharacter.html#foldCa=
se(int,
boolean), not the 'full case folding'. For example I can create "ss.txt" an=
d
"=C3=9F.txt"

windows also doesn't lowercase any supplementary characters.

In other words, its case comparison acts exactly like
String.equalsIgnoreCase(). So, for File.hashCode(), a hashcode computed wit=
h
Character.toLowerCase(Character.toUpperCase(char)) would be completely
consistent with its case sensitivity.

--=20
Robert Muir
rcmuir@gmail.com

--0016368e1f82544ccf0490fae759--