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
