<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks for pointing me to that recent fix! I’ve confirmed it solves the issue. As the problem is still present on jdk17 and jdk11, I’ll seek a backport to solve the issue there as well.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks again,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Stephanie<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Naoto Sato <naoto.sato@oracle.com><br>
<b>Date: </b>Friday, June 17, 2022 at 8:52 AM<br>
<b>To: </b>Alan Bateman <Alan.Bateman@oracle.com>, Stephanie Crater <scrater@microsoft.com>, jdk-dev@openjdk.org <jdk-dev@openjdk.org><br>
<b>Subject: </b>[EXTERNAL] Re: Error if argument passed to java.exe contains non-ASCII character<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">[You don't often get email from naoto.sato@oracle.com. Learn why this is important at
<a href="https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!ACWV5N9M2RV99hQ!OAcZxSsN57unJxy_yyH8PtHnFL2b7iYCNWiRw2t9JvULGbTCTDQRh_dM2eLLIZL1AGG8E80Hmz_0_78Z6m9t$">https://aka.ms/LearnAboutSenderIdentification</a> ]<br>
<br>
IIRC, the issue relates to the JVM invocation interface, which takes CLI<br>
options as `char *` in platform's encoding. So even if the launcher is<br>
UNICODE enabled, it ends up passing the arguments in platform<br>
characters, i.e., back to `???`s to the created JVM.<br>
<br>
Having said that, recently Microsoft has chnaged its direction on<br>
supporting Unicode apps:<br>
<br>
<a href="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdocs.microsoft.com*2Fen-us*2Fwindows*2Fapps*2Fdesign*2Fglobalizing*2Fuse-utf8-code-page&data=05*7C01*7Cscrater*40microsoft.com*7C8b1f421416cc4eb6adf508da50795cfa*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637910779447463057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=M8qfsixgxLMcX51GgG5mpU7iGKz6Stdi1snup6vxg68*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!ACWV5N9M2RV99hQ!OAcZxSsN57unJxy_yyH8PtHnFL2b7iYCNWiRw2t9JvULGbTCTDQRh_dM2eLLIZL1AGG8E80Hmz_0_0PHY0PR$">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fapps%2Fdesign%2Fglobalizing%2Fuse-utf8-code-page&data=05%7C01%7Cscrater%40microsoft.com%7C8b1f421416cc4eb6adf508da50795cfa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637910779447463057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=M8qfsixgxLMcX51GgG5mpU7iGKz6Stdi1snup6vxg68%3D&reserved=0</a><br>
<br>
where it reads:<br>
<br>
```<br>
Until recently, Windows has emphasized "Unicode" -W variants over -A<br>
APIs. However, recent releases have used the ANSI code page and -A APIs<br>
as a means to introduce UTF-8 support to apps. If the ANSI code page is<br>
configured for UTF-8, -A APIs typically operate in UTF-8. This model has<br>
the benefit of supporting existing code built with -A APIs without any<br>
code changes.<br>
```<br>
<br>
So they are now recommending using ANSI interface, with UTF-8 as the<br>
system default encoding. This perfectly fits our situation. With the fix<br>
recently made (<a href="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.org*2Fbrowse*2FJDK-8272352&data=05*7C01*7Cscrater*40microsoft.com*7C8b1f421416cc4eb6adf508da50795cfa*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637910779447463057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=1yMQpreCl*2FtZEojoFOBrpnotCQH7aBk2s08*2BfjdsNJ4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!OAcZxSsN57unJxy_yyH8PtHnFL2b7iYCNWiRw2t9JvULGbTCTDQRh_dM2eLLIZL1AGG8E80Hmz_0__WntQ41$">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.org%2Fbrowse%2FJDK-8272352&data=05%7C01%7Cscrater%40microsoft.com%7C8b1f421416cc4eb6adf508da50795cfa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637910779447463057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1yMQpreCl%2FtZEojoFOBrpnotCQH7aBk2s08%2BfjdsNJ4%3D&reserved=0</a>),
JDK now is<br>
capable of dealing with non-ASCII paths on Windows with UTF-8 system<br>
encoding.<br>
<br>
HTH,<br>
Naoto<br>
<br>
<br>
On 6/17/22 7:55 AM, Alan Bateman wrote:<br>
> On 17/06/2022 00:53, Stephanie Crater wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I've been investigating an error on Windows in which compilation fails<br>
>> when the SDK file path includes a Chinese character (and more broadly,<br>
>> if any string argument passed to java.exe contains a non-ASCII<br>
>> character). This happens because command line arguments are read using<br>
>> GetCommandLine() [1]. In the Windows file processenv.h, this resolves<br>
>> to GetCommandLineW [2] if UNICODE is defined and GetCommandLineA [3]<br>
>> otherwise. As UNICODE is not defined, GetCommandLineA is used and<br>
>> Chinese characters on the command line are converted to "?", causing<br>
>> the following:<br>
>><br>
>> Compilation failed with an internal error.<br>
>><br>
>> Exception in thread "main" java.nio.file.InvalidPathException: Illegal<br>
>> char <?> at index 34: C:\Program Files<br>
>> (x86)\Android\SDK????\platforms\android-31\android.jar<br>
>><br>
>> This error has been reported before, including JDK-8124977 [4]<br>
>> (describes command line encoding challenges on Windows, created in<br>
>> 2015 and still unresolved)<br>
>><br>
><br>
> Someone in Microsoft did propose a patch in 2015 on this. It lead to an<br>
> 8 month discussion on the issues/implications (the core-libs-dev archive<br>
> from 2015 and 2016). Several things have changed since then, including<br>
> moving to UTF-8 by default and defining system properties for the native<br>
> and console encoding. I don't disagree that it may be time to look at<br>
> this again. The core-libs-dev mailing list is the right place rather<br>
> than jdk-dev.<br>
><br>
> -Alan<o:p></o:p></span></p>
</div>
</div>
</body>
</html>