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

[Xueming Shen]

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