<i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets

[Ichiroh Takiguchi]

On Thu, 7 Jul 2022 09:47:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> And also there is no reason why db drivers or host connectors should not ship their own charset support \(Oracle JDBC for example had nls\_charset addons\. My employer also ship a custom EBCDIC encoding which includes some compatibility hacks\, and that took some effort to adopt it to the missing ext mechanism\)\.
>> 
>> Having said that\, with JPMS a \?legacy ebcdic\? encoding module would be possible while still being optional\. Maybe in the future a mechanism for modules which can be added \(instead of removed\) from standard distribution would make that nicer\?
>> 
>> Is there a performance restriction for charset if they are not part of a platform module \(optimized string access\)\?
>> 
>> Gruss
>> Bernd
>> 
>> 
>> \-\-
>> http\:\/\/bernd\.eckenfels\.net
>> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>> Von\: core\-libs\-dev \<core\-libs\-dev\-retn at openjdk\.org> im Auftrag von Alan Bateman \<alanb at openjdk\.org>
>> Gesendet\: Thursday\, July 7\, 2022 11\:50\:39 AM
>> An\: build\-dev at openjdk\.org \<build\-dev at openjdk\.org>\; core\-libs\-dev at openjdk\.org \<core\-libs\-dev at openjdk\.org>\; i18n\-dev at openjdk\.org \<i18n\-dev at openjdk\.org>
>> Betreff\: Re\: RFR\: 8289834\: Add SBCS and DBCS Only EBCDIC charsets
>> 
>> On Wed\, 6 Jul 2022 16\:18\:08 GMT\, Ichiroh Takiguchi \<itakiguchi at openjdk\.org> wrote\:
>> 
>>> Discussions are available on \:
>>> \[JDK\-8289834\]\(https\:\/\/bugs\.openjdk\.org\/browse\/JDK\-8289834\)\: Add SBCS and DBCS Only EBCDIC charsets
>> 
>> Yes\, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets\. I understand they can be useful for someone using JDBC to connect to a database on z\/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path\. Do you know if the icu4j project is still alive\? I\'ve often wondered why there wasn\'t more use of the provider mechanism\.
>> 
>> \-\-\-\-\-\-\-\-\-\-\-\-\-
>> 
>> PR\: https\:\/\/git\.openjdk\.org\/jdk\/pull\/9399
>> \-\-\-\-\-\-\-\-\-\-\-\-\-\- next part \-\-\-\-\-\-\-\-\-\-\-\-\-\-
>> An HTML attachment was scrubbed\.\.\.
>> URL\: \<https\:\/\/mail\.openjdk\.org\/pipermail\/core\-libs\-dev\/attachments\/20220707\/2d095f3d\/attachment\-0001\.htm>
>
>> Discussions are available on :
>> [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets
> 
> Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism.

Hello @AlanBateman .
Sorry I'm late.
I got some responses from ICU. [ICU-22091](https://unicode-org.atlassian.net/browse/ICU-22091)
I'm not sure if they're interested in the new charset...

As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage.
And some other performance advantages are there on built-in charset decoder/encoder.
Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes?
We'd like to use stable conversion loop.

-------------

PR: https://git.openjdk.org/jdk/pull/9399