Review/comment needed for the new public java.util.Base64 class

[Weijun Wang]

On 10/11/2012 11:09 AM, Xueming Shen wrote:
> On 10/10/12 6:51 PM, Weijun Wang wrote:
>> Several questions:
>>
>> 1. In encode0(byte[] src, byte[] dst)
>>
>>  281                 if (linepos == linemax && (atom != 0 || sp < sl)) {
>>
>> Maybe atom != 0 is not necessary?
>
> The logic here is that if we reached the last atom (atom == 0), but if
> there
> is still byte(s) in src (sp < sl), we will need to output the last
> special unit,
> which has one or two padding charactere '=', in this case, we still need to
> output the line separator(s).

But when atom != 0, it seems sp < sl should always be true.

-Max

>
>>
>> 2. Is it necessary to explicitly mention in the spec that there is no
>> CrLf at the end of a MIME encoded string?
>
> I'm struggling with which is the appropriate/desired behavior, output
> the crlf for the last line
> or not. Apache's common coder appears to append the crlf for the last
> line, but our sun.misc
> version does not (but sun.misc.BASE64 actually appends the line
> separator if the last line
> happens to have 76 characters, I would assume this is a bug though). The
> current implement
> tries to match the sun.misc. I'm happy to go either way.
>
> But, as you suggested, it might be worth explicitly describing whatever
> behavior we choose.
>
>>
>> 3. The test confirms decoding can correctly reverse the encoding but
>> it says nothing about the correctness of the encoding. Maybe we can
>> just use "10.  Test Vectors" of RFC 4648?
>>
>
> I do have a version of TestBase64 actually compares encoded results of
> j.u.Base64,
> sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
> I should
> at least plug in the code for comparing with sun.misc.Base64Encoder.
>
> Thanks!
> -Sherman
>
>
>>
>>
>> On 10/11/2012 01:54 AM, Xueming Shen wrote:
>>>
>>> A standard/public API for Base64 encoding and decoding has been long
>>> overdue. JDK8  has a JEP [1] 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 [2].  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
>>>
>>> [1] http://openjdk.java.net/jeps/135
>>> [2] http://cr.openjdk.java.net/~sherman/base64/
>