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

[Xueming Shen]

Thanks Alan!

The webrev has been updated to throw OOME as your other nio native 
dispatcher does.

http://cr.openjdk.java.net/~sherman/7130915/webrev.

I can wait for your back from the vacation:-)

-Sherman


On 6/26/12 11:41 PM, Alan Bateman wrote:
> 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
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/i18n-dev/attachments/20120627/f44a0a2a/attachment-0001.html