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

[Alan Bateman]

On 27/06/2012 04:33, Xueming Shen wrote:
> Alan,
>
> Webrev has been updated accordingly at
>
> http://cr.openjdk.java.net/~sherman/7130915/webrev
>
> with changes
>
> (1) added a CFStringCreateMutable(...) != null check in both io and 
> nio native, though it is
>      unlikely  to fail here because we are passing a NULL and 0 
> length, like new StringBuilder()
>      invocation, if it fails the system probably goes very wrong. Both 
> FStringAppendCharacters
>      and CFStringNormalize are void return type.
>
> (2) The first line of path.toCharArray in normalizeJavaPath is a typo, 
> it is supposed to be
>      deleted. The implementation only goes toCharArray when it needs 
> to go native. Currently
>      it uses >0x80 as the fast path criteria, it is possible to expose 
> some sun.text.normalizer's
>      internal methods to have a "quick nfc" check, but I'm not sure 
> how much the performance
>      gain would be, but might worth some investigation later.
>
> (3) Comments have been added for those override-able methods in 
> UnixFileSystem.
>
> (4) blank lines have been removed from dispatcher.c
>
> (5) I don't think we need to do the HFS check, given we are only doing 
> nfc/nfd stuff now, as
>      long as it is a MacOSX, I believe its nfc/nfd layer will be 
> there. Copyright has been re-copy/
>      pasted and we now only use only bugid.
>
> -Sherman
I'm heading away on vacation now and only quickly scanned the updated 
webrev. All looks okay to me. On the calls to the CF functions then one 
thing is that if they fail (and this is unlikely I know) then you won't 
have an exception pending so may need to add code to call one of the 
JNU* functions to throw OOME, otherwise it might cause a NPE in the 
caller rather than throwing an exception as you would expect.

-Alan