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

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

-Sherman

On 10/12/2012 12:47 PM, Ariel Weisberg wrote:
> Hi,
>
> Thanks for doing this BTW.
>
> I think that including ByteBuffer API even if it isn't as efficient as
> raw byte arrays is better then not having it in the API at all. If that
> means allocating a byte array for the output and then doing a put on the
> ByteBuffer that is fine.
>
> Down the line if someone has a particularly powerful itch to scratch WRT
> to performance they can add more code to the library to make it more
> efficient at handling them and then everyone will benefit or they can do
> their own implementation.
>
> Thanks,
> Ariel
>
>
> On Fri, Oct 12, 2012, at 02:56 PM, Xueming Shen wrote:
>> Hi,
>>
>> The exactly reason I was trying to skip en/decode(ByteBuffer in,
>> ByteByuffer out)
>> for now. I'm struggling with/can't make up my mind on whether or not the
>> en/decoder
>> should  have internal state, like the charset en/decoder. It appears the
>> API is being
>> pushed going that direction though:-)
>>
>> -Sherman
>>
>> On 10/12/2012 11:39 AM, Michael Schierl wrote:
>>> Hello,
>>>
>>> (sorry if the threading is broken, but I was not subscribed to the list
>>> and only found the discussion on Twitter and read it in the mailing list
>>> archive)
>>>
>>> Ariel Weisberg wrote on Thu Oct 11 11:30:56 PDT 2012:
>>>> I know that ByteBuffers are pain, but I did notice that you can't
>>>> specify a source/dest pair when using ByteBuffers and that ByteBuffers
>>>> without arrays have to be copied. I don't see a simple safe way to
>>>> normalize access to them the way you can if everything is a byte array.
>>> Agreed. One of the advantages of using byte buffers is reducing
>>> allocations, resulting in fewer garbage collections.
>>>
>>> In addition, in this implementation the ByteBuffers have to contain the
>>> full data.
>>>
>>> What I like about most byte buffers APIs is that I can pass in a
>>> ByteBuffer with incomplete data or maybe an output ByteBuffer that is
>>> too small to hold the complete result, and it will just process as much
>>> as it can, and leave the rest for the next round (which should work well
>>> for Base64, too, as it always processes chunks of 3 or 4 bytes).
>>>
>>> So, a useful ByteBuffer API in my opinion needs a method like
>>>
>>> public boolean encode(ByteBuffer in, ByteBuffer out,
>>>     boolean endOfInput);
>>>
>>> public boolean decode(ByteBuffer in, ByteBuffer out,
>>>     boolean endOfInput);
>>>
>>> (similar to CharsetEncoder#encode) that can process partial input and
>>> will return true if all processable input has been processed (i. e. in
>>> has to be refilled) or false if some input could not have been processed
>>> (i. e. out has to be flushed).
>>>
>>> Users have to call it again and again until they call it with
>>> endOfInput=true and get true back (Using an enum as result similar to
>>> CoderResult#UNDERFLOW and CoderResult#OVERFLOW might be another option
>>> if the boolean results are too cryptic).
>>>
>>> Having a ByteBuffer Base64 API might be useful (although I'm not sure
>>> yet if I ever need it), but as it is now, it is mostly useless for
>>> serious ByteBuffer usage, as if I have to split and copy the data
>>> manually anyway, I can as well use the array APIs.
>>>
>>>
>>> Just my 0.02 EUR,
>>>
>>>
>>> Michael