StandardCharset vs. StandardCharsets

[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 see the fact that the String method variants that takes a Charset are 
slower that the ones that use a String
as a performance bug, not as a design issue.

The String method that takes a Charset should reuse the class-local decoder
and the performance problem will go away.
(The analysis in StringCoding.decode(Charset, ...) (point 1) forget that 
initializing a decoder has also a cost)

Rémi
PS: also the else part of if(c instanceof ArrayDecoder) should be in a 
side method to ease
       the inlining of decode().