On Thu, 7 Jul 2022 09:47:25 GMT, Alan Bateman <al...@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
