StandardCharset vs. StandardCharsets

Rémi Forax forax at
Sat May 7 16:00:36 UTC 2011

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 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)

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

More information about the core-libs-dev mailing list