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
