StandardCharset vs. StandardCharsets

[Ulf Zibis]

Am 08.05.2011 10:33, schrieb Xueming Shen:
>  On 5/7/2011 10:55 AM, Ulf Zibis wrote:
>>
>> I agree 50 %.
>> 100 % would be to have:
>>     byte[] String.getBytes(CharsetEncoder encoder)
>>     String(byte[] bytes, CharsetDecoder decoder)
>> So for convenience in consequence we should introduce constants for CharsetDecoder's and 
>> CharsetEncoder's in j.n.c.StandardCharsets, which would result in 12 additional classes to be 
>> loaded and instatiated at one time, if only one of them becomes in use.
>>
>
> Ulf,
>
> CharsetDecoder and CharsetEncoder have "states", can't be used as a "constant".
>
> -Sherman
>

Yes, I know, remember I'm fully against the j.n.c.StandardCharsets concept. I would support 
declaration of the the charset names at 1 place.
I only wanted to point out, that caching de/encoders would make more sense than caching charsets 
(which are anyway cached by Charset; ...and additionally the small local cache becomes destroyed 
from initialization of j.n.c.StandardCharsets) at least from the performance view.
Maybe it could make sense to have those de/encoders as ThreadLocal constants, as it should be easy 
for the user to care about the state:
- after usage from String.getBytes etc. state should be "ready for new work"
- in other cases user may use reset()..

But the user anyway could cache them in his code, so it would be big support to have:
     byte[] String.getBytes(CharsetEncoder encoder)
     String(byte[] bytes, CharsetDecoder decoder)

-Ulf