StandardCharset vs. StandardCharsets

[Ulf Zibis]

Am 08.05.2011 11:13, schrieb 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)
>

I have reported a bug:
7043095 - Provide fast de/encoding for String 
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7043095>

-Ulf