On Wed, 28 Sep 2022 09:45:32 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).
>
> KIRIYAMA Takuya has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails
> on Japanese Windows platform
test/jdk/tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java line 55:
> 53: String encoding = System.getProperty("native.encoding");
> 54: switch (encoding) {
> 55: default:
What I meant by the previous comment was to replace this `default` clause to:
case "Cp1252", "UTF-8" -> testString = new
String(Character.toChars(0x00E9));
And for other unknown encodings:
default -> {
System.out.println("Test skipped"); // or better message
return;
}
And your fix:
case "MS932", "SJIS" -> testString = new String(Character.toChars(0x3042));
This way only the encodings that are guaranteed to succeed are tested.
-------------
PR: https://git.openjdk.org/jdk/pull/10226
