StandardCharset vs. StandardCharsets

Xueming Shen 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:
>>> 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



More information about the core-libs-dev mailing list