RFR: 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform
KIRIYAMA Takuya
duke at openjdk.org
Wed Sep 28 09:45:33 UTC 2022
On Wed, 14 Sep 2022 21:07:41 GMT, Naoto Sato <naoto at 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).
>
> `native.encoding` holds the host encoding that used to be `file.encoding`.
> Another suggestion is that, the test should only run in encodings that are guaranteed to succeed, e.g., `Cp1252` or `UTF-8`, otherwise it should gracefully exit. Your proposed fix could still fail in locales/encodings other than SJIS/MS932.
@naotoj
Thank you for your help. I fixed this test to use native.encoding.
It is difficult to add all the encodings, so I will fix for Japanese and would like people who need other languages to do the same.
-------------
PR: https://git.openjdk.org/jdk/pull/10226
More information about the core-libs-dev
mailing list