<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 09/29/2011 02:16 PM, Ulf Zibis wrote:
    <blockquote cite="mid:4E84E025.3010105@gmx.de" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Please use spaces with ternary operators: Lines 155, 216<br>
      <br>
      For short you could use sr instead srcRemaining, consistent to sa,
      sp, sl.<br>
      <br>
      &nbsp;420&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // returns -1 if there is malformed byte(s) and the<br>
      better:<br>
      &nbsp;420&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // returns -1 if there is/are malformed byte(s) and
      the<br>
      <br>
      &nbsp;466&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sp -=3;<br>
      There should be a space:&nbsp; sp -= 3;<br>
    </blockquote>
    <br>
    Webrev has been updated accordingly.<br>
    <br>
    <blockquote cite="mid:4E84E025.3010105@gmx.de" type="cite"> <br>
      &nbsp;280&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (Character.isSurrogate(c))<br>
      &nbsp;281&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return malformedForLength(src, sp,
      dst, dp, 3);<br>
      Shouldn't we return cr.length() = 1to allow remaining 2 bytes to
      be interpreted again ?<br>
      <br>
    </blockquote>
    <br>
    Actually I don't know the answer. My reading of D93a/D93b suggests
    that we might<br>
    interpret it as a whole, given the bytes are actually in well-formed
    byte pattern range<br>
    listed in Table 3.7, but "ill-formed" simply because they are
    surrogate value not scale<br>
    value, so I would interpret the whole 3 bytes as a maximal subpart.
    Given D93a/b is<br>
    "best practices for Using U+fffd", either way should be fine. We do
    have Unicode expert<br>
    on the list, so maybe they can share their opinion on what is the
    "desired"/recommended<br>
    behavior in this case, from Standard point view?<br>
    <br>
    <blockquote cite="mid:4E84E025.3010105@gmx.de" type="cite"> <br>
      Am 29.09.2011 05:27, schrieb Xueming Shen:
      <blockquote cite="mid:4E83E591.2090103@oracle.com" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        Hi,<br>
        <br>
        On 9/28/2011 3:44 PM, Ulf Zibis wrote:
        <blockquote cite="mid:4E83A350.5010102@gmx.de" type="cite"> 5.
          IMHO charset CESU-8 should be hosted in extended-charsets,
          otherwise it should be added to java.nio.StandardCharsets<br>
          <br>
        </blockquote>
        <br>
        We have lots of charsets provided via the "standard charset
        provider" (in rt.jar) but not listed in StandardCharsets.<br>
      </blockquote>
      Yes, but the reasonable to add CESU-8 to StandardCharsets was the
      supposed demand to treat all unicode charsets equivalent.<br>
      <br>
      Otherwise there is no obstacle to host CESU-8 in
      extended-charsets.<br>
      IMHO, CESU-8 addresses corner case compatibility issues, but not
      "standard" requirements.<br>
    </blockquote>
    <br>
    To put CESU-8 into "standard charset provider" (it is only an
    implementation details) does<br>
    not mean it is a "standard" requirement, it just means it is bundled
    into rt.jar. The reason<br>
    I put it there is to make sure it is together with the UTF-8, with
    the assumption is that you<br>
    might need it around when using the updated UTF-8, which no longer
    handles those 3/6-byte<br>
    surrogates.<br>
    <br>
    -Sherman<br>
    <br>
    <br>
  </body>
</html>