StandardCharset vs. StandardCharsets
xueming.shen at oracle.com
Sun May 8 08:33:49 UTC 2011
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:
>>> 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.
CharsetDecoder and CharsetEncoder have "states", can't be used as a
More information about the core-libs-dev