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

[Peter Levart]

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