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

[Xueming Shen]

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