<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">nitpicks<br>
      <br>
      (1) personally I prefer the "commented out" one-line code, don't
      see the value-add<br>
           of storing it into "base64EncodedCertString"<br>
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <pre><span class="changed">   //out.println(Base64.getMimeEncoder().encodeToString(encoded));</span></pre>
      (2) X509Factory.java:<br>
           Wouldn't it be more reasonable if the "data" was byte[]?<br>
           Understand we may want to avoid touching the original code
      logic if it is really<br>
           not necessary (performance could be the motivation, if
      performance matters here)<br>
      <br>
      (3) keytool/Main.java<br>
           #358 #558, two extra blank lines, if not intentional<br>
      <br>
      (4) I see couple places in the code base that use new
      String(byte[]) without explicitly<br>
           specifying an encoding (which implies the default system
      decoding). My guess is<br>
           that maybe we should use something explicit? This has nothing
      to do with this<br>
           base64 migration though.<br>
           <br>
      Looking at the use cases, I think we may seriously consider Mike's
      suggestion to<br>
      use sharedsecret to improve the performance of de/encoding from/to
      String.<br>
      <br>
      -Sherman<br>
      <br>
      On 2/14/13 5:24 AM, Mark Sheppard wrote:<br>
    </div>
    <blockquote cite="mid:511CE592.9010901@oracle.com" type="cite">Hi,
      <br>
         as part of a refactoring of the jdk codebase to use the base64
      capabilities of java.util.Base64,  the following modifications,
      <br>
      as per the webrev,
      <br>
      <br>
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~chegar/8006182/webrev.00/">http://cr.openjdk.java.net/~chegar/8006182/webrev.00/</a>
      <br>
      <br>
      have been made to complete task JDK-8006182.
      <br>
      <br>
      Could you oblige and review these changes, please?
      <br>
      <br>
      Description:
      <br>
      jdk8 has java.util.Base64 to define a standard API for base64
      encoding/decoding. It would be good to investigate whether this
      API could be used in the security components, providers and
      regression tests.
      <br>
      <br>
      In the main this work involved replacing the
      sun.misc.BASE64Encoder and sun.misc.BASE64Decoder with the
      <br>
      corresponding Mime Base64 Encoder/Decoder  (as per rfc2045) from
      the java.util.Base64 class.
      <br>
      This is a like for like replacement.
      <br>
      As such, sun.misc.BASE64Encoder maps to the encoder returned by
      java.util.Base64.getMimeEncoder()
      <br>
      sun.misc.BASE64Decoder maps to the decoder returned by
      java.util.Base64.getMimeDecoder()
      <br>
      <br>
      However a couple of items worth noting:
      <br>
      <br>
      In the jarsigner  (Main.java) the standard Base64 encoder (rfc
      4648), java.util.Base64.getEncoder(), has been used to replace the
      JarBASE64Encoder, which was a package private extension of
      BASE64Encoder, which avoids writing newline to the encoded data.
      <br>
      <br>
      In the keytool (Main.java), methods such as dumpCert, printCert.
      printCRL, and so on, write a Base64 encoding to an OutputStream,
      typically std out.
      <br>
      This is achieved in the BASE64Encoder, by passing the OutputStream
      to methods such as encodeBuffer().
      <br>
      <br>
      A couple of options exist to do this under the new Base64
      utilities, which include:
      <br>
      <br>
      * using a Mime Encoder encodeToString() and  output to the stream
      via println()
      <br>
      <br>
      * use the wrap capabilities of the Base64.Encoder:
      <br>
          - define a package private class, which extends
      FilterOutputStream (e.g. NoCloseWrapperOutputStream) and,
      overrides close() to do nothing
      <br>
          - inject the OutputStream,  passed to the keytool method, into
      the NoCloseWrapperOutputStreamwapper,
      <br>
          - wrap() the NoCloseWrapperOutputStreamwrapper in the Mime
      Encoder, which will in turn return an encapsulating OutputStream;
      <br>
          - write the data buffer to be encoded to the encoder's
      OutputStream;
      <br>
          - close the encoder's OutputStream, which completes the base64
      encoding;
      <br>
          - append a newline to the initial OutputStream.
      <br>
      <br>
      pragmatics and the simplest thing that works, went for the first
      option.
      <br>
      <br>
      regards
      <br>
      Mark
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>