Bug ID: JDK-8275145 file.encoding system property has an incorrect value on Windows

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17	JDK 18
17.0.2Fixed	18 b20Fixed

https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-October/082387.html

The `file.encoding` system property should be set to sprops->sun_jnu_encoding for platforms except MacOS but a regression introduced in JDK-4947890 that set its value to sprops->encoding instead.

#ifdef MACOSX
        /*
         * Since sun_jnu_encoding is now hard-coded to UTF-8 on Mac, we don't
         * want to use it to overwrite file.encoding
         */
        PUTPROP(props, "file.encoding", sprops->encoding);
#else
        PUTPROP(props, "file.encoding", sprops->sun_jnu_encoding);
#endif

Fix request (17u): Request to include in 17u, applies cleanly, all relevant tests passed.
18-10-2021
This CSR has fixVersion=18 and I think needs to be clarified that it only changes the behaviour in JDK 18 when running with -Dfile.encoding=COMPAT. We really need a CSR for 17u to provide the complete story. I think it might be better to not have a RN for JDK 18, the reason is that the main change in JDK 18 is changing to UTF-8 by default and it would be confusing to say that the compatibility mode has been fixed (as this "mode" this does exist in prior releases). A release note for 17u is important of course.
16-10-2021
Changeset: ad9e234f Author: Naoto Sato <naoto@openjdk.org> Date: 2021-10-15 20:36:30 +0000 URL: https://git.openjdk.java.net/jdk/commit/ad9e234f5ed61635f926618a40f453fe7b6b491f
15-10-2021
Thanks for the updates. Given that -Dfile.encoding=COMPAT sets encoding based on the user rather than system locale then I assume we will have to make a change in JDK 18 too.
14-10-2021
I checked JDK18's file.encoding and sun.jnu.encoding system properties. Default setting --- file.encoding = UTF-8 sun.jnu.encoding = MS932 --- With -Dfile.encoding=COMPAT option --- file.encoding = Cp1252 sun.jnu.encoding = MS932 ---
14-10-2021
My understanding of this issue is that this happens when the system locale and the user locale are not the same ones on Windows. Say, if the system locale is set to `Japanese (Japan)` and the user locale is set to `English (US)`, which I believe the submitter's case, then: JDK11: --- file.encoding = MS932 sun_jnu_encoding = MS932 --- JDK17: --- file.encoding = Cp1252 sun_jnu_encoding =MS932 ---
13-10-2021
[~naoto] Would you have cycles to look at this one as this area is fresh in your mind?
13-10-2021
This issue may not be applicable to JDK 18 as file.encoding will be UTF-8 and the JDK-internal/undocumented sun.jnu.encoding will be the same as before. I checked a Windows Server 2019 system with JDK 11 and JDK 17 and both file.encoding and sun.jnu.encoding are set to Cp1252 as expected. The reported issue seem to be Japanese Windows 10 so I can't easily check. The mail to core-libs-dev uses the phrase "working behavior was changed" but I can't tell if this is an environment where file.encoding has been changed or not.
13-10-2021

CSR :	JDK-8275309 - file.encoding system property has an incorrect value on Windows
Relates :	JDK-4947890 - Minimize JNI upcalls in system-properties initialization