Review/comment needed for the new public java.util.Base64 class
ariel at weisberg.ws
Thu Oct 11 18:30:56 UTC 2012
It looks like it tackles the issue of encoding binary data as text in an
isolated fashion and doesn't seem open to adding other ways of encoding
binary data as text such as hex or yEnc. Having a common interface in
java.util for different encodings would be great. I am not asking for
more implementation, just a more abstract interface for Decoder and
I know that ByteBuffers are pain, but I did notice that you can't
specify a source/dest pair when using ByteBuffers and that ByteBuffers
without arrays have to be copied. I don't see a simple safe way to
normalize access to them the way you can if everything is a byte array.
On Thu, Oct 11, 2012, at 12:40 PM, Xueming Shen wrote:
> On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
> > The class level javadoc is quite short. It also has hyperlinks in the
> > first sentence, which means that they are visible in package level
> > javadoc. Consider having no hyperlinks in the first sentence, and
> > expanding a little on what base 64 is.
> Sure, will come up something longer.
> > There are lots of other public base 64 implementations to test/check against.
> > http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html
> > http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html
> > http://migbase64.sourceforge.net/ (claims to be fast)
> I did compare the result against the apache version, the difference
> appears to
> be the apache (1)append line feeds at the end of the encoded bytes
> (2)skip the
> padding '=' characters for URL-safe style. Will try other
> > The arrays are defined inconsistently within the code (3 styles).
> > private Encoder(byte base64, byte newline, int linemax)
> > byte  getBytes(ByteBuffer bb)
> > private static final byte toBase64 =
> > I'd strongly encourage one style be used, and that it is the first of
> > the three above.
> Good catch, the later two are not intentional, the leftover of old code.
> webrev has
> been updated according.
> > Stephen
> > On 10 October 2012 18:54, Xueming Shen<xueming.shen at oracle.com> wrote:
> >> A standard/public API for Base64 encoding and decoding has been long
> >> overdue. JDK8 has a JEP  for this particular request.
> >> Here is the draft proposal to add a public Base64 utility class for JDK8.
> >> http://cr.openjdk.java.net/~sherman/4235519/webrev
> >> This class basically provides 4 variants of Base64 encoding scheme,
> >> (1) the default RFC 4648, which uses standard mapping, no line breaks,
> >> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace "+"
> >> and
> >> "/" for the mapping
> >> (3) the default MIME style, as in RFC 2045 (and its earlier versions), which
> >> uses
> >> "standard" base64 mapping, a 76 characters per line limit and uses crlf
> >> pair
> >> \r\n for line break.
> >> (4) an extend-able MIME base64, with the char-per-line and the line
> >> separator(s)
> >> specified by developer.
> >> The encoder/decoder now provides encoding and decoding for byte, String,
> >> ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream",
> >> which we believe/hope should satisfy most of the common use cases.
> >> Additional
> >> method(s) can be added if strongly desired.
> >> We tried couple slightly different styles of design for such this "simple"
> >> utility
> >> class . We kinda concluded that the version proposed probably provides
> >> the best balance among readability, usability and extensibility.
> >> Please help review and comment on the API and implementation.
> >> Thanks!
> >> -Sherman
> >>  http://openjdk.java.net/jeps/135
> >>  http://cr.openjdk.java.net/~sherman/base64/
More information about the core-libs-dev