Constants for standard charsets -- CR #4884238

Ulf Zibis Ulf.Zibis at
Tue Apr 12 19:10:18 UTC 2011

Am 12.04.2011 20:27, schrieb Mike Duigou:
> On Apr 12 2011, at 11:11 , mark.reinhold at wrote:
>> 2011/4/12 10:38 -0700, mike.duigou at
>>> On Apr 12 2011, at 03:33 , Alan Bateman wrote:
>>>> ...
>>>> 2. @see Charsets.DEFAULT, I assume this should be @see Charsets#DEFAULT_CHARSET
>>> Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link.
>> Why is forcing people to type Charsets.DEFAULT_CHARSET better than
>> Charsets.DEFAULT?
>> If DEFAULT_CHARSET needs the _CHARSET suffix then don't the other
>> constants need that too?  Why is DEFAULT special?
> The addition of _CHARSET is to encourage static import of Charsets. Unadorned DEFAULT has too much chance of collision. The other defined names shouldn't collide.

For me, Charsets.DEFAULT should be enough:
1.) Looks better.
2.) Usage of those constants should be rare, so static import should be rare too. So prevent 
developpers from typing more than neccessary.
3.) We stay in current tradition. Remember Integer.MAX_VALUE, Long.MAX_VALUE etc...

... but anyway, we drop it.

BTW: I too miss the original post of this thread in my emails. Problem with the mail server ?

 > This change has been previously proposed but the constants were to be defined in Charset which 
was deemed to have too high a static initialization cost. Using a separate class, Charsets, means 
that the cost for initialization is only borne by those who use the class--there's virtually no 
incremental cost to platform initialization.

I can't agree with that, because you statically invoke e.g. Charset.forName("US-ASCII"), which 
causes the expensive initialization of the Charset class.

Please note my long waiting patches:
***Bug 100091* <> - No system start for 
*****Bug 100092* <> - Speed-up FastCharsetProvider
*****Bug 100095* <> - Avoid 2-step lookup in 
sun.nio.cs charset providers
*****Bug 100098* <> - Make sun.nio.cs.* charset 
objects light-weight


More information about the core-libs-dev mailing list