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

[Peter Levart]

On 10/13/2012 11:21 AM, Peter Levart wrote:
> One way to do it without state in encoder is 1st as suggested to have 
> the 'endOfStream' flag and in addition when new-line breaks are 
> requested, to only encode "full lines" at each invocation. So If one 
> wants to use this line-breakage feature he/she must make sure that 
> there is enough space (line_size+2 at worst) left in destination buffer
...and (forgot to add) enough bytes remaining in source buffer or the 
endOfStream==true...
> to do any encoding or the encoder will not do anything (return 0 or 
> false).
>
> Regards, Peter
>
> On 10/12/2012 10:58 PM, Xueming Shen wrote:
>>
>> Yes, I'm trying to figure out where to have this  position info 
>> stored...
>>
>> On 10/12/2012 01:48 PM, Michael Schierl wrote:
>>> Am 12.10.2012 22:12, schrieb Xueming Shen:
>>>> Hi,
>>>>
>>>> It appears to be possible to do something like
>>>>
>>>> boolean de/encode(ByteBuffer src, ByteBuffer dst);
>>>>
>>>> returns true if all remaining bytes in src are en/decoded, false, 
>>>> the dst
>>>> is not big enough for all output bytes, the src.position() will be 
>>>> advanced
>>>> to the position of next un-en/decoded byte, dst.position() will be 
>>>> updated
>>>> accordingly as well.
>>>>
>>>> to avoid the en/decoder to hold an internal state.
>>> If it was unclear, that was what I tried to suggest. I thought you
>>> refered to the automatic adding of newlines when you said you'd need
>>> internal state (although that state is small enough - how many encoded
>>> bytes remaining before adding the next newline - so that it might be
>>> possible to pass it as a parameter, too). I'm not sure how important
>>> that adding of newlines really is (in all cases where I was guilty of
>>> using sun.misc.Base64Encoder, I always replaced them out after
>>> encoding), so maybe the ByteBuffer API could live without it.
>>>
>>> Note that without an explicit end of stream flag, it might not be 
>>> easily
>>> possible to encode the last block - if you have a 16 byte buffer 
>>> with 14
>>> bytes filled, you cannot be sure whether you can encode the last two
>>> bytes to XYZ= because it is end of stream or you have to wait for the
>>> next byte. An option without the flag might be to assume when the input
>>> is less than 3 bytes that it is the end of the stream. But I doubt it
>>> will make the API easier to understand or use. :-)
>>>
>>>
>>> Regards,
>>>
>>>
>>> Michael
>>
>