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

[Xueming Shen]

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