harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: [classlib][luni] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)
Date Fri, 24 Sep 2010 05:46:24 GMT
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 "σ.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.
>

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#foldCase(int,
boolean), not the 'full case folding'. For example I can create "ss.txt" and
"ß.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 with
Character.toLowerCase(Character.toUpperCase(char)) would be completely
consistent with its case sensitivity.

-- 
Robert Muir
rcmuir@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message