<i18n dev> Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
Alan.Bateman at oracle.com
Tue Jun 26 23:41:37 PDT 2012
On 27/06/2012 04:33, Xueming Shen wrote:
> Webrev has been updated accordingly at
> 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
> 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
> (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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the i18n-dev