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-r...@openjdk.org> im Auftrag von Alan Bateman <al...@openjdk.org> Gesendet: Thursday, July 7, 2022 11:50:39 AM An: build-dev@openjdk.org <build-dev@openjdk.org>; core-libs-...@openjdk.org <core-libs-...@openjdk.org>; i18n-...@openjdk.org <i18n-...@openjdk.org> Betreff: Re: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets On Wed, 6 Jul 2022 16:18:08 GMT, Ichiroh Takiguchi <itakigu...@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
