[JDK-8275145] file.encoding system property has an incorrect value on Windows Created: 2021-10-12 Updated: 2025-04-03 Resolved: 2021-10-15 | |
| Status: | Resolved |
| Project: | JDK |
| Component/s: | core-libs |
| Affects Version/s: | 12 |
| Fix Version/s: | 18 |
| Type: | Bug | Priority: | P3 |
| Reporter: | Mandy Chung (Inactive) | Assignee: | Naoto Sato |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | jdk17u-fix-SQE-ok, jdk17u-fix-request, jdk17u-fix-yes, noreg-hard, regression | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | Not Specified | Time Spent: | Not Specified |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Issue Links: |
| ||||||||||||||||||||||||||||
| Sub-Tasks: |
| ||||||||||||||||||||||||||||
| Subcomponent: | java.io | ||||||||||||||||||||||||||||
| Resolved In Build: | b20 | ||||||||||||||||||||||||||||
| CPU: | generic | ||||||||||||||||||||||||||||
| OS: | windows | ||||||||||||||||||||||||||||
| 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 #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 |
| Comment byNaoto Sato ] |
| Fix request (17u): Request to include in 17u, applies cleanly, all relevant tests passed. |
| Comment byAlan Bateman ] |
| 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. |
| Comment byRobo Duke ] |
| 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 |
| Comment byAlan Bateman ] |
| 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. |
| Comment byIchiroh Takiguchi ] |
| 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 --- |
| Comment byNaoto Sato ] |
| 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 --- |
| Comment byAlan Bateman ] |
| [~naoto] Would you have cycles to look at this one as this area is fresh in your mind? |
| Comment byAlan Bateman ] |
| 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. |