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

[Xueming Shen]

On 10/18/2012 6:19 AM, Ulf Zibis wrote:
> Hi Sherman,
>
> you could create the code table by help of a String constant, which 
> would speed up the loading and save a little footprint on the class 
> file. (you have forgotten those tricks from sun.nio.cs coders? ;-) )

The implementation probably needs more tuning.

>
> But my main question:
> Why don't you enqueue those coders in the well known sun.nio.cs.ext 
> provider?

Base64 encoding is not a charset. Mainly it is supposed to be 
byte[]<->byte[] coding.
Even for byte[]<=>char[]/String, Base64 "encode" byte[] to char[]/String 
and "decode"
from char[]/String to byte[]. The "wrong" direction compared to charset 
en/decoder.

> At least, I think, class Base64 should be hosted in java.nio.charset 
> rather than common java.util.
> As I believe, that the usage of this encoding is far from common

you might be surprised how "common" it might be:-)

-Sherman

> , adding it to the lazy loaded charsets.jar IMO should be more 
> reasonable.
>
> -Ulf
>
>
> Am 18.10.2012 04:10, schrieb Xueming Shen:
>> 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
>>
>