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

Xueming Shen xueming.shen at oracle.com
Tue Jun 26 06:00:13 UTC 2012

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/71309157168427/webrev (The webrev for the "full" version has been moved to http://cr.openjdk.java.net/~sherman/71309157168427/webrevfull) 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/71309157168427/webrev/ Here is the brief summary of the changes java.io.File: (1) removed nfc->nfd conversion in ioutil.h/WITHPLATFORMSTRING, 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 murmur332(), 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

More information about the core-libs-dev mailing list