<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks Alan!<br>
      <br>
      The webrev has been updated to throw OOME as your other nio native
      dispatcher does.<br>
      <br>
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~sherman/7130915/webrev">http://cr.openjdk.java.net/~sherman/7130915/webrev</a>.<br>
      <br>
      I can wait for your back from the vacation:-)<br>
      <br>
      -Sherman<br>
      <br>
      <br>
      On 6/26/12 11:41 PM, Alan Bateman wrote:<br>
    </div>
    <blockquote cite="mid:4FEAAB21.9050205@oracle.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      On 27/06/2012 04:33, Xueming Shen wrote:
      <blockquote cite="mid:4FEA7F1E.4070500@oracle.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">Alan,<br>
          <br>
          Webrev has been updated accordingly at<br>
          <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://cr.openjdk.java.net/%7Esherman/7130915/webrev">http://cr.openjdk.java.net/~sherman/7130915/webrev</a><br>
          <br>
          with changes<br>
          <br>
          (1) added a <span class="changed">CFStringCreateMutable(...)
            != null check in both io and nio native, though it is<br>
            &nbsp; &nbsp;&nbsp; unlikely&nbsp; to fail here because we are passing a NULL
            and 0 length, like new StringBuilder()<br>
            &nbsp; &nbsp;&nbsp; invocation, if it fails the system probably goes very
            wrong. Both </span>
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          FStringAppendCharacters<br>
          &nbsp;&nbsp;&nbsp;&nbsp; and
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          CFStringNormalize are void return type.<br>
          <br>
          (2) The first line of path.toCharArray in normalizeJavaPath is
          a typo, it is supposed to be<br>
          &nbsp;&nbsp;&nbsp;&nbsp; deleted. The implementation only goes toCharArray when it
          needs to go native. Currently<br>
          &nbsp;&nbsp;&nbsp;&nbsp; it uses &gt;0x80 as the fast path criteria, it is
          possible to expose some sun.text.normalizer's<br>
          &nbsp;&nbsp;&nbsp;&nbsp; internal methods to have a "quick nfc" check, but I'm not
          sure how much the performance<br>
          &nbsp;&nbsp;&nbsp;&nbsp; gain would be, but might worth some investigation later.<br>
          <br>
          (3) Comments have been added for those override-able methods
          in UnixFileSystem.<br>
          <br>
          (4) blank lines have been removed from dispatcher.c<br>
          <br>
          (5) I don't think we need to do the HFS check, given we are
          only doing nfc/nfd stuff now, as<br>
          &nbsp;&nbsp;&nbsp;&nbsp; long as it is a MacOSX, I believe its nfc/nfd layer will
          be there. Copyright has been re-copy/<br>
          &nbsp;&nbsp;&nbsp;&nbsp; pasted and we now only use only bugid.<br>
          <br>
          -Sherman<br>
        </div>
      </blockquote>
      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.<br>
      <br>
      -Alan<br>
      <br>
    </blockquote>
    <br>
    <br>
  </body>
</html>