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
