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

[Xueming Shen]

Michael,


The current approach assumes that the base64 en/decoding of a file, stream
will be handled by the en/decoder.wrap(...). The en/decode(bb, bb) is 
basically
for one time invocation input and output from/to existing buffers, with the
hope of avoiding the coding-life-circle management, so it assumes all input
will be passed in in the src buffer and only needs limit support for 
cases that
the existing output buffer is not sufficient. We will probably have to 
go with
the "endOfInput" flag approach, if the current version is still not 
enough for
most of "common" use cases.

-Sherman


On 10/18/2012 11:01 AM, Michael Schierl wrote:
> Am 18.10.2012 04:10, schrieb Xueming Shen:
>> Hi
>>
>> Webrev has been updated with following changes
>>
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
> I think line 443 needs an additional check for atom == 0. Same for the
> array case. At least if you do not want an endOfInput flag in the
> parameters. If you have an endOfInput flag, you can use that in the
> condition instead of atom == 0.
>
> Consider this example where trying to encode 25 bytes using an input
> ByteBuffer of 16 bytes and an output ByteBuffer of 32 bytes (Of course,
> you'd use larger buffers in practice, but the same can happen with
> larger buffers too, as long as your buffer size is not divisible by
> three, or you do not completely fill the buffer with each read. Both can
> happen if the media you are reading from uses a different sector/block
> size - like when attaching a base64 attachment of a large file from disk
> to an email).
>
> First you fill 16 bytes of input into input buffer, then you call encode
> the first time. it will encode the first 15 bytes to 20 bytes of output,
> then encode the 16th byte to XY==. You flush the output and fill the
> next 9 bytes into the input buffer. The next call to encode will encode
> the 9 bytes to 12 bytes. So, in total you have 36 bytes, but the padding
> is in the middle.
>
> With the check, the first call will encode the first 15 bytes to 20
> bytes of output and leave the 16th byte in the buffer. You flush the
> output and load 9 bytes to the 1 remaining byte in the input buffer. The
> second call will encode the first 9 bytes to 12 bytes and leave one byte
> left over. You flush the buffer and call a third time, which will encode
> the last byte to XY==. Still 36 bytes, this time with padding at the end.
>
>
> Regards,
>
>
> Michael