Error if argument passed to java.exe contains non-ASCII character

Naoto Sato naoto.sato at oracle.com
Fri Jun 17 15:52:13 UTC 2022


IIRC, the issue relates to the JVM invocation interface, which takes CLI 
options as `char *` in platform's encoding. So even if the launcher is 
UNICODE enabled, it ends up passing the arguments in platform 
characters, i.e., back to `???`s to the created JVM.

Having said that, recently Microsoft has chnaged its direction on 
supporting Unicode apps:

https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

where it reads:

```
Until recently, Windows has emphasized "Unicode" -W variants over -A 
APIs. However, recent releases have used the ANSI code page and -A APIs 
as a means to introduce UTF-8 support to apps. If the ANSI code page is 
configured for UTF-8, -A APIs typically operate in UTF-8. This model has 
the benefit of supporting existing code built with -A APIs without any 
code changes.
```

So they are now recommending using ANSI interface, with UTF-8 as the 
system default encoding. This perfectly fits our situation. With the fix 
recently made (https://bugs.openjdk.org/browse/JDK-8272352), JDK now is 
capable of dealing with non-ASCII paths on Windows with UTF-8 system 
encoding.

HTH,
Naoto


On 6/17/22 7:55 AM, Alan Bateman wrote:
> On 17/06/2022 00:53, Stephanie Crater wrote:
>>
>> Hi,
>>
>> I've been investigating an error on Windows in which compilation fails 
>> when the SDK file path includes a Chinese character (and more broadly, 
>> if any string argument passed to java.exe contains a non-ASCII 
>> character). This happens because command line arguments are read using 
>> GetCommandLine() [1]. In the Windows file processenv.h, this resolves 
>> to GetCommandLineW [2] if UNICODE is defined and GetCommandLineA [3] 
>> otherwise. As UNICODE is not defined, GetCommandLineA is used and 
>> Chinese characters on the command line are converted to "?", causing 
>> the following:
>>
>> Compilation failed with an internal error.
>>
>> Exception in thread "main" java.nio.file.InvalidPathException: Illegal 
>> char <?> at index 34: C:\Program Files 
>> (x86)\Android\SDK????\platforms\android-31\android.jar
>>
>> This error has been reported before, including JDK-8124977 [4] 
>> (describes command line encoding challenges on Windows, created in 
>> 2015 and still unresolved)
>>
> 
> Someone in Microsoft did propose a patch in 2015 on this. It lead to an 
> 8 month discussion on the issues/implications (the core-libs-dev archive 
> from 2015 and 2016). Several things have changed since then, including 
> moving to UTF-8 by default and defining system properties for the native 
> and console encoding. I don't disagree that it may be time to look at 
> this again. The core-libs-dev mailing list is the right place rather 
> than jdk-dev.
> 
> -Alan


More information about the jdk-dev mailing list