On Fri, 9 Sep 2022 08:30:55 GMT, KIRIYAMA Takuya <d...@openjdk.org> wrote:
> Could you please review the JDK-8293579 bug fixes? > > tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java attempts to give > the launcher the character which is encoded by Windows API > WideCharToMultiByte() > from UNICODE "é"(0x00e9) as an argument. However, this test fails because the > code point "é"(0x00e9) cannot be treated on Japanese Windows. > > WideCharToMultiByte() encodes characters as Shift-JIS on Japanese Windows, > but > the code point "é"(0x00e9) does not exist in Shift-JIS, and it is replaced > with > "e"(0x0065) as substitute. Therefore, "é"(0x00e9) and "e"(0x0065) are > compared > in this test and judged to be different characters, and return as failed. > > So, in the Japanese encoding("MS932", "SJIS"), the test should be modified to > give a character such as "あ"(0x3042) as the launcher's argument instead of > "é"(0x00e9). I just wonder if the fix is working as intended... Since JDK18, `file.encoding` is always `UTF-8` with JEP 400, so the switch expression seems to fall into the `default` clause? ------------- PR: https://git.openjdk.org/jdk/pull/10226