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

[Xueming Shen]

On 10/18/12 7:43 AM, Alan Bateman wrote:
> On 18/10/2012 03:10, Xueming Shen wrote:
>> Hi
>>
>> 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.
>>
>> webrev:
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> some performance scores:
>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>
>> -Sherman
> 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.

-Sherman
>