RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18 [v2]
Ichiroh Takiguchi
itakiguchi at openjdk.org
Tue Jan 24 12:30:06 UTC 2023
On Mon, 23 Jan 2023 13:46:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> It's never been supported to run with -Dfile.encoding=Cp943C. It may have worked in JDK 8 but I doubt it could have worked consistently since JDK 9 because the default charset is derived before it's possible to locate charset implementations outside of java.base.
As described before, JDK17 worked with `-Dfile.encoding=Cp943C`, and JDK18 changed the behavior. I heard some apps had already ported on JDK17 with the option, and works.
> I think it would be useful to know a bit more about the environment. It sounds like it might be AIX -> Linux migration but I'm curious if you have any insight into why these applications depend on default charset being Cp943C. Is it text files that are opened without specifying the charset or is is something else?
One of my client has many legacy Java apps on AIX. Their apps use default charset to communicate with other apps via cipher communication, and validate data by using Cp943C.
I hope IBM943C is moved to java.base module, like #11908 .
-------------
PR: https://git.openjdk.org/jdk/pull/12132
More information about the core-libs-dev
mailing list