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