RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v2]

[Ichiroh Takiguchi]

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at 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