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

[Ariel Weisberg]

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
>