Yes, I believe the issue described in MACOSX_PORT-165 is the
same issue this patch is trying to solve.

Btw, it appears there are typos in the note(2), my mini keyboard obviously
is too sticky:-)

(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.

-sherman

On 6/24/12 7:50 AM, David Kocher wrote:
Will this address issue MACOSX_PORT-165 [1]?

[1] http://java.net/jira/browse/MACOSX_PORT-165

-- David

On 22.06.2012, at 19:01, 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->nfd before 
passing
     back to java.io.File (File.list() and canonicalize()), so we deal with 
nfdc 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



Reply via email to