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

Ulf Zibis Ulf.Zibis at CoSoCo.de
Thu Oct 18 15:27:26 UTC 2012

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

More information about the core-libs-dev mailing list