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
