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=QnyZ1rtVbEp/y4zT0u09YpFzfBiw/stNTl9OgYZqFNNJWy3wz8JghOEWX/3hV9kZjA
         r4lsJIWtmhOGAAwDGC9Kw+Z5NqatqutZyTkvmpveoLr1SSdclGM6dJSy+H3PvK7kT/I1
         d2DMuDK/CrISjxKkIoxvELwmV0GDEs4CaWRwI=
MIME-Version: 1.0
In-Reply-To: <4C9C31BD.2010504@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>
From: Robert Muir <rcmuir@gmail.com>
Date: Fri, 24 Sep 2010 01:13:42 -0400
Message-ID: <AANLkTimpEm+ZTC=esH0SR1yoiGO-bZMm=UytLL9R=ug9@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=001636c5b1f468e4a60490fa72e0

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

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 "=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 hashcode
based upon String.toLowerCase(Locale.ENGLISH) would return different
hashcodes for these two filenames, but with UCharacter.foldCase(), it would
be the same.

--=20
Robert Muir
rcmuir@gmail.com

--001636c5b1f468e4a60490fa72e0--