RFR: 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform [v2]

[John Platts]

The issue can be worked around on Windows 10 Version 1903 or later (including Windows 11) by modifying the src/java.base/windows/native/launcher/java.manifest file as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0"
          xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
>
<assemblyIdentity
    name=""
    version=""
    processorArchitecture="X86"
    type="win32"
/>
<description>Java(TM) SE process</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>

  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="asInvoker"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

  <!-- Indicate JDK is high-dpi aware. -->
  <asmv3:application>
    <asmv3:windowsSettings xmlns:dpi1="http://schemas.microsoft.com/SMI/2005/WindowsSettings"
                           xmlns:dpi2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"
                           xmlns:utf8="http://schemas.microsoft.com/SMI/2019/WindowsSettings">
      <dpi1:dpiAware>true/PM</dpi1:dpiAware>
      <dpi2:dpiAwareness>PerMonitorV2, PerMonitor, system</dpi2:dpiAwareness>
      <!-- Use UTF-8 as the active code page on Windows 10 version 1903 or later -->
      <utf8:activeCodePage>UTF-8</utf8:activeCodePage>
    </asmv3:windowsSettings>
  </asmv3:application>

  <!-- Indicate this JDK version is Windows 7 compatible -->
   <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
      <application>
        <!-- Windows Vista -->
        <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
        <!-- Windows 7 -->
        <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
        <!-- Windows 8 -->
        <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
        <!-- Windows 8.1 -->
        <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
        <!-- Windows 10 -->
        <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
      </application>
    </compatibility>
</assembly>

The GetACP() and GetOEMCP() functions will both return 65001 on Windows 10 Version 1903 or later if the above changes are made to src/java.base/windows/native/launcher/java.manifest.

Also make sure that the sun.jnu.encoding property is set to UTF-8 if GetACP() returns 65001.

Note that it is possible for GetACP() and GetOEMCP() to return values other than 65001 on Windows 10 Version 1809 or earlier or if the JVM is embedded in an application that does not have the <utf8:activeCodePage>UTF-8</utf8:activeCodePage> setting in its manifest.

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Naoto Sato <naoto at openjdk.org>
Sent: Wednesday, September 28, 2022 1:03 PM
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8293579: tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java fails on Japanese Windows platform [v2]

On Wed, 28 Sep 2022 09:45:32 GMT, KIRIYAMA Takuya <duke 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).
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221003/729d085d/attachment-0001.htm>