StandardCharset vs. StandardCharsets
Ulf.Zibis at gmx.de
Mon May 9 16:00:14 UTC 2011
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.
>> CharsetDecoder and CharsetEncoder have "states", can't be used as a "constant".
> 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
More information about the core-libs-dev