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

[Ulf Zibis]

Am 18.10.2012 16:04, schrieb Xueming Shen:
>
> On 10/18/2012 6:19 AM, Ulf Zibis wrote:

Oops, you are working at 6 in the morning?

>> 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.

Hopefully, some day we have arrays of primitive types in the class file's constant pool.

>> 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.

1:0 for you.
I only had the ASCII/Unicode characters -> Base64 "en"coding in mind, which seems in fact a 
Java-String to byte[] to char[]/String 2-step-encoding.

>
>> 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:-)

or surprised, why it wasn't part of the JDK before.

-Ulf