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-r...@openjdk.org> on behalf of Naoto Sato
<na...@openjdk.org>
Sent: Wednesday, September 28, 2022 1:03 PM
To: core-libs-dev@openjdk.org <core-libs-dev@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 <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
