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