On 5/7/2011 10:55 AM, Ulf Zibis wrote:
Rémi, thanks for your feedback.
Am 07.05.2011 18:00, schrieb Rémi Forax:
On 05/07/2011 02:17 PM, Ulf Zibis wrote:
Hi all,
please excuse, that I have still problems to accept this additional
class, but +1 for the plural name.
If those charset constants are there, people _will use_ them without
respect on the existing _performance disadvantages_.
A common typical use case should be: String.getBytes(...)
On small strings there is a performance lost up to 25 % using the
charset variant vs. the charset name variant. See:
http://cr.openjdk.java.net/~sherman/7040220/client
http://markmail.org/message/2tbas5skgkve52mz
http://markmail.org/thread/lnrozcbnpcl5kmzs
So I still think, we should have the standard charset names as
constants in class j.n.c.Charset:
public static final String UTF_8 = "UTF-8"; etc...
Using objects instead of string is a better design.
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
