Constants for standard charsets -- CR #4884238

[Ulf Zibis]

Am 13.04.2011 14:33, schrieb Alan Bateman:
> Ulf Zibis wrote:
>> :
>>
>> Please note my long waiting patches:
>> ***Bug 100091* <https://bugs.openjdk.java.net/show_bug.cgi?id=100091> - No system start for 
>> file.encoding=x-SJIS_0213
>> *****Bug 100092* <https://bugs.openjdk.java.net/show_bug.cgi?id=100092> - Speed-up 
>> FastCharsetProvider
>> *****Bug 100095* <https://bugs.openjdk.java.net/show_bug.cgi?id=100095> - Avoid 2-step lookup in 
>> sun.nio.cs charset providers
>> *****Bug 100098* <https://bugs.openjdk.java.net/show_bug.cgi?id=100098> - Make sun.nio.cs.* 
>> charset objects light-weight
> I don't know if anyone is looking at these and I don't know how up to date they are. How about 
> re-basing them and restarting the discussion here once jdk8 has opened? It would be best to focus 
> on a single issue at a time and separate out the reformatting of the code to a separate patch.
>
Yes, but if we have added the Charsets class to JDK-7 we can't remove it later. Is CR #4884238 
essential for JDK-7 ? I think we can too move this CR to JDK-8, so we wouldn't miss the advantages 
of my proposed changes, or we could add the constants to the existing Charset class.

I still think, initializing those 6 simple charsets is nothing against initializing Charset class, 
which happens anyway at system start, and even less after integrating ***Bug 100098* 
<https://bugs.openjdk.java.net/show_bug.cgi?id=100098> - Make sun.nio.cs.* charset objects light-weight.
In this change, the then light-weight charset objects (each of same class in contrary to today's one 
separate class per charset) are directly initialized in the Charset's lookup map instead their 
canonical String names, so lookup would become very fast, and the huge mapping data of some charsets 
would get cached by SoftReference, which actually doesn't hold on today's approach.

-Ulf