JDK-8205991 : Cannot start application (WinLauncher) if path contains non-ascii character
  • Type: Bug
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: 14,15,16
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2018-06-13
  • Updated: 2021-01-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8029584 - Allow \uxxxx unicode-escaping on the jvm command-line arguments
Blocks :  
JDK-8221508 - Cannot run java.exe from folder if path contains non-ASCII character
Duplicate :  
JDK-8232936 - Non-ascii are handled incorrectly by generated exe
Description
ADDITIONAL SYSTEM INFORMATION :
Windows 10 1803, Java SE Development Kit 10.0.1

Broken: Windows 10 1803 + ����, ����, ���� or ����
Broken: Windows 10 1511 + ���� or ����
OK: Windows 10 1709 + ���� or ����
OK: Windows 10 1511 + ���� or ����

A DESCRIPTION OF THE PROBLEM :
The application will not start on Windows 10 1803 if the installation path has non-ascii character.

If the app is installed under C:\Users\User\AppData\Local\FooClient\ then FooClient app will start properly.
If the app is installed under C:\Users\Fr����deric\AppData\Local\FooClient\ then FooClient app wont start.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Use Windows 10 Professional 1803, Oracle Java SE Development Kit 10.0.1 and Inno Setup 5.5.9 (u)
2. Source code of the minimum app:

FooClient.java:
import javax.swing.*;

public class FooClient {

    public static void main(String[] args) {
        javax.swing.SwingUtilities.invokeLater(() -> {
            JFrame frame = new JFrame("HelloWorldSwing");
            frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
            frame.pack();
            frame.toFront();
            frame.setVisible(true);
        });
    }
}

3. Build it with the following commands
"C:\Program Files\Java\jdk-10.0.1\bin\javac" FooClient.java
"C:\Program Files\Java\jdk-10.0.1\bin\jar" cfe fooclient.jar FooClient FooClient.class
"C:\Program Files\Java\jdk-10.0.1\bin\javapackager" -deploy -native installer -outdir . -srcdir . -srcfiles fooclient.jar -appclass FooClient -verbose

It produces a native Windows exe package: FooClient-1.0.exe

4. Start the installer on Windows 1803
5. Application is installed under C:\Users\%USERNAME%\AppData\Local\FooClient\
6. If your username has a non-ascii (eg ���� or ����) character then application will not start.
7.1. Rename C:\Users\%USERNAME%\AppData\Local\FooClient to C:\Users\%USERNAME%\AppData\Local\FooClient���� and the C:\Users\%USERNAME%\AppData\Local\FooClient����\FooClient.exe will not start.
7.2. Rename C:\Users\%USERNAME%\AppData\Local\FooClient to C:\Users\%USERNAME%\AppData\Local\FooClienta and the C:\Users\%USERNAME%\AppData\Local\FooClienta\FooClient.exe will start.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application starts properly even when the path contains non-ascii characters.
ACTUAL -
Application terminates almost immeditely: for a few millisecs there is a running FooClient.exe process but then it terminates.

CUSTOMER SUBMITTED WORKAROUND :
Install application to a directory where the path does not contain ascii characters.

FREQUENCY : always
Comments
Blocked by JDK-8029584
11-01-2021
Set fix version to tbd, since it requires JDK-8029584 to be fixed which has fix version tbd.
17-04-2020
Further more information from another submitter of JI-9063055: This issue still exists in jpackage Build 14-jpackage+1-70 (2019/11/12) on Windows 10. It is preventing us to release user-based installations, as umlauts (German a", o", for example: Unicode char U+00E4) may be present in the user folder path, resulting in the application not starting at all without any feedback or error message. Adding java.exe to the bundled runtime environment, and launching manually from command line with the classpath and parameters taken from bundled "app\[application].cfg" does *not* exhibit this bug. Calling the starter exe in a path with umlauts results in immediately return to command line, in the fraction of a second. No JVM startup (would take longer), no error message returned, even if called from shell. I suspect the problem happens when reading and passing the environment strings to the Windows API for creating the JVM, as the java.exe works seamless. Altering the app config file, one can see that this is a general character set problem passing the arguments. To track down the problem I did the following: - placing two copies of my app in two directories c:\test and c:\testa" (the a" being a German umlaut, Unicode char U+00E4, I can't post it here) - Launcher will start in test but not testa" - replacing "$ROOTDIR" with hardcoded path to "c:\test" in the config file "c:\testa"\app\[application.cfg], I can successfully start the launcher in c:\testa" - but changing the path in app.runtime or app.classpath from "C:\test\runtime" to "C:\testa"\runtime", the app doesn't start anymore The .cfg file is read as UTF-8 and converted to Windows multibyte UTF-16 when loading (Platform::LoadFromFile calling WindowsPlatform::InitStreamLocale() which returns "std::locale(empty_locale, newstd::codecvt_utf8<wchar_t>())". Any other encoding of the file (ANSI, Iso-8851, ...) results in a "runtime not found" error. This means no matter what the current directory detection method based on GetModuleFileName() returns for $ROOTDIR, there is a problem passing the parameters on to Java. I guess the bug might happen at # WindowsPlatform.cpp, line 355 TString runtimeBin = GetPackageRuntimeBinDirectory(); SetDllDirectory(runtimeBin.c_str()); - or - # JavaVirtualMachine.cpp, line 278 std::string arg = PlatformString(item).toStdString(); where the wide UTF-16 encoded Windows strings should converted to a proper multibyte/Unicode string for passing. I couldn't find out more, but I hope this enough information to find the source quickly.
12-12-2019
I do not think we have problem in code mentioned above. When I debug it, it failed inside JLI this is why I filed JDK-8221508. We need to wait for JDK-8221508 to fix this issue.
11-12-2019
Root cause for this issue is JDK-8221508. Keeping this bug open to re-test/fix after JDK-8221508 is resolved.
26-03-2019
I was able to reproduce it by renaming output folder of jpackage to "Test����" on Windows 7.
23-03-2019
A developer reported the following: "I can reproduce the issue with Oracle JDK 8u201. This is a regression somewhere after 8u144. Probably due to a backport from JDK 10." I am adding "8u201" to the affected version (although it may affect earlier versions as well) and listing it as a regression, since it used to work in 8u144.
08-03-2019
Itried simple app with "--name simple-����" also tried renaming output directory of simple app from "output" to "output-����" I could run the app in both cases. I cannot reproduce this on Windows 7 with latest jpackage, need to test on Windows 10.
06-03-2019
it is reported this issue still exist in jpackage EA, so reopening
08-02-2019
The issue is reported with Windows 10 Version 1803 and JDK 10.0.1. Java application fails to start when the installation path has non-ascii character. Results: ========== 9 - Ok 10.0.1: Fail 11 ea b19: NA This is a regression in JDK 10. However, the issue does not qualify for JDk 11 considering javapackager Removal from JDK 11. To verify, run the following steps: 1. Use Windows 10 Professional 1803, Oracle Java SE Development Kit 10.0.1 and Inno Setup 5.5.9 (u) 2. Compile the atatched test code 3. Build it with the following commands "C:\Program Files\Java\jdk-10.0.1\bin\javac" FooClient.java "C:\Program Files\Java\jdk-10.0.1\bin\jar" cfe fooclient.jar FooClient FooClient.class "C:\Program Files\Java\jdk-10.0.1\bin\javapackager" -deploy -native installer -outdir . -srcdir . -srcfiles fooclient.jar -appclass FooClient -verbose This produces a native Windows exeutable package: FooClient-1.0.exe 4. Install from FooClient-1.0.exe 5. Application is installed under C:\Users\%USERNAME%\AppData\Local\FooClient\ 6. Run the application from C:\Users\%USERNAME%\AppData\Local\FooClient\FooClient.exe Note that the application launches fine. 7. Now, add a non-ascii (eg ���� or ����) character and run the executable again. This time the application will fail to launch. example path: Rename C:\Users\%USERNAME%\AppData\Local\FooClient to C:\Users\%USERNAME%\AppData\Local\FooClient���� 8. Renaming it back or to ASCII character, say FooClienta and run the executable again. This time the application will launch successfully. Apparently, non-ascii character in the path fails the application to start.
28-06-2018
As noted, the javapackager has been removed from JDK 11, so we will not fix this bug. A new jpackager tool is being developed as a replacement for javapackager (see JDK-8200758). We can test this use case with the new tool and address it if the problem still exists.
28-06-2018