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

[Xueming Shen]

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).

>
> 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/