RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
xueming.shen at oracle.com
Sat May 30 01:26:39 UTC 2015
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 ...
More information about the core-libs-dev