On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8285517: System.getenv() returns unexpected value if environment variable >> has non ASCII character > > Can you clarify the use of different charset properties for the > ProcessEnvironment vs the CommandLine strings? > > They are used to decode or encode strings in the APIs to native functions > respectively. > If I understand `native.encoding` was introduced to reflect the default > encoding of file contents, while `sun.jnu.encoding` is used to encode > filenames. > > I think I would have expected to see `sun.jnu.encoding` to be used in all > contexts when encoding/decoding strings to the native representations. > (Assuming its not required for backward compatibility). Hello @RogerRiggs . When I executed the new testcase with JDK18.0.1, I got following errors: ERROR: argument EUC_JP_TEXT is: Actual: \u7FB2\u221A\uFFFD Expected: \u6F22\u5B57 ERROR: Variable EUC_JP_TEXT is encoded by: Actual: \xE6\xBC\xA2\xE5\xAD\x97 Expected: \xB4\xC1\xBB\xFA ERROR: Value EUC_JP_TEXT is encoded by: Actual: \xE6\xBC\xA2\xE5\xAD\x97 Expected: \xB4\xC1\xBB\xFA The new testcase verifies internal byte data for EUC_JP_TEXT environment variable and value. ------------- PR: https://git.openjdk.java.net/jdk/pull/8378
