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

[Weijun Wang]

On 10/11/2012 11:32 AM, Xueming Shen wrote:
> On 10/10/12 8:16 PM, Weijun Wang wrote:
>>
>>
>> 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.
>
> Yes, the sp < sl part only counts if atom == 0. Means if it's NOT last
> atom,
> (atom != 0) output the line feeds, if it IS the last atom (atom == 0), only
> output the line feeds if there are leftover byte (sp < sl), which means the
> last 4-byte unit (with one or two '=') will be after this line feed.

So, the value of sp < sl is always the same as (atom != 0 || sp < sl). 
That's why I said atom != 0 is not necessary.

-Max

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