<i18n dev> Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X

[Xueming Shen]

On 6/25/12 10:58 PM, Xueming Shen wrote:
> Hi,
>
> While I still believe that case-insensitive is the right choice for 
> File/Path on MacOSX, it is
> suggested that we might want to be a little conservative in this 
> patch, with the assumption
> that this patch will be backport to 7u release after being baked in 
> jdk8 for a while (given
> Apple's JDK6 is case sensitive for File, it might be too much for a 
> update releases to go
> with two in-compatible changes, case sensitive and hash32).
>
> So here is the webrev for a strip-down version from the original 
> patch, in which it only
> targets the nfd/nfc issue raised in 7130915 and 7168427. The proposed 
> changes for
> case insensitive compare and hash32 for both java.io.File and 
> java.nio.file.Path are
> removed.
>
> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev
>
> (The webrev for the "full" version has been moved to
>  http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full)
>
> Thanks,
> -Sherman
>
>
> On 6/22/12 10:01 AM, Xueming Shen wrote:
>> Hi
>>
>> Here is the proposed change to support Unicode nfd/nfc and case 
>> insensitive
>> file path on MacOSX file system.
>>
>> 7130915: File.equals does not give expected results when path 
>> contains Non-English characters on Mac OS X
>> 7168427: FileInputStream cannot open file where the file path 
>> contains asian characters [macosx]
>>
>> While these two bug reports are only against java.io, we have the 
>> same issue in javax.nio.file.
>> Here is the webrev
>>
>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/
>>
>> Here is the brief summary of the changes
>>
>> java.io.File:
>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, 
>> which means
>>      we are now passing nfc/composite characters directly into macosx 
>> file system APIs
>>      without  normalize them to nfd. It appears macosx fs APIs do 
>> take nfc, though it uses
>>      nfd.
>>
>> (2) normalize the resulting file name from macosx fs APIs from 
>> nfd->nfc before passing
>>      back to java.io.File (File.list() and canonicalize()), so we 
>> deal with nfc file name
>>      (as "usual")  for java.io classes/APIs.
>>
>> (3) fs.compare()/hashCode() was updated to be case insensitive
>>
>> (4) hasCode() was updated to use the new String.hash32().
>>
>> java.nio.file:
>>
>> (5) added a setof MacOSXFile... on top of existing BsdFile... 
>> classes. An alternative is to
>> update those BsdFile... classes directly to address the macosx 
>> specific issues. But given
>> there might be developers over there might work on open jdk BSD port 
>> and have dependency
>> on these classes, it might be desirable to have another separate 
>> layer of MacOSXFile...
>> classes. So now the default FileSystem/Provider is 
>> MacOSXFileSystemProvider and
>> MacOSXFileSystem.
>>
>> (6)  the "main" changes are in MacOSXFileSystem, in which the 
>> corresponding methods
>> were added to handle, case insensitive and nfd<=>nfc normalization, 
>> including the
>> pathmatcher.
>>
>> (7) compare is now are case-insensitive
>>
>> (8) hashCode is now murmur3_32(), this is true for all 
>> Solaris/Unix/Linux and maxosx.
>>
>>
>> Though lots of files have been touched, but the line of changes are 
>> actually relatively
>> small.
>>
>> The proposed change only deals with the default case-sensitiveness 
>> seting, which is
>> case insensitive. On MaxOSX, you actually can configure the HFS+ file 
>> system or the
>> mounted vol to be case-sensitive. A possible approach is to have some 
>> extra FileStore
>> attributes, such as a isCaseSensitive and to use case sensitive 
>> compare/equal on
>> such fs, but this can be dealt with separately later.
>>
>> Thanks,
>> -Sherman
>
>