Review/comment needed for the new public java.util.Base64 class (original) (raw)

Xueming Shen 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:

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

More information about the core-libs-dev mailing list