Review/comment needed for the new public java.util.Base64 class
xueming.shen at oracle.com
Thu Oct 18 15:12:18 UTC 2012
On 10/18/12 7:43 AM, Alan Bateman wrote:
> On 18/10/2012 03:10, Xueming Shen wrote:
>> Webrev has been updated with following changes
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>> (2) some minor spec clarification regarding the "end of decoding"
>> (3) performance tuning.
>> some performance scores:
> Have you done any performance tuning on the new methods that
> encode/decode into an existing ByteBuffer? Just wondering as the
> direct buffer case seems more expensive that I would expect. It would
> be interesting to see using the put(int,byte) and fixing up the
> position at the end would help. It might also be something to look at
> with the compiler folks.
no "real" tuning yet on the direct buffer case. Just tried to get the
API out for review/comment first.
> In any case, I think encode(ByteBuffer,ByteBuffer,int) looks
> reasonable and just requires using the idiom to get it right. I'm less
> sure about decode returning a boolean. Shouldn't it be an error if
> there are bytes remaining after the = padding?
It depends on expectation. Padding partially serves as a "end of base64
byte stream" indicator.
> I'm just looking for ways to allow the method return an int to
> indicate the number of bytes written to the output buffer (and realize
> that we aren't going to get symmetry with the encode method).
Yes, even a "int" return value will not get us the symmetry with
encode(bb, bb). A boolean return provides
a more liberal behavior.
More information about the core-libs-dev