RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

Ulf Zibis Ulf.Zibis at CoSoCo.de
Sat May 30 17:37:57 UTC 2015

Am 30.05.2015 um 03:26 schrieb Xueming Shen:
> On 5/29/15 4:02 PM, Ulf Zibis wrote:
>> Am 29.05.2015 um 19:42 schrieb Xueming Shen:
>>> But if it is decided later that we may want to have a separate ext charsets provider2, for 
>>> example to split most of the ibm charsets to a separate provider, it might be desired to keep it 
>>> as a base class ...
>> Hm, is it mandatory, that each charset provider must have it's own class?
>> I also think, that we do not need a separate class for each charset.
> No, it's not a "must" to have a separate class for each charset, but it's a logical way to 
> organize those
> charset with their data. Given how most of these charsets are src-generated in current jdk, it's 
> fair easy
> to actually generate a "charset" object from a base classes (SingleByte, or DoubleByte) + a set of 
> "data"
> ( such as the name, aliases table, mapping data, etc) during runtime, without having a real concrete
> charset class. But then you need to figure out a better way to organize, store and 
> read/initialize  those
> "data" in a optimized way to initialize each charset on the fly, which we are now utilizing the jvm's
> class initialization mechanism to achieve this. Any benefit/advantage of doing this? We might throw
> in some resource someday to gather some data ...

Hi sherman,

I did some work here:
Unfortunately the data was moved somewhere. Do you know, where the data was moved?
One of the original bug reports: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6862158

Also I did some work here:


More information about the core-libs-dev mailing list