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