Review/comment needed for the new public java.util.Base64 class
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.
More information about the core-libs-dev