JDK-8242283 : Can't start JVM when java home path includes non-ASCII character
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 15
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2020-04-07
  • Updated: 2021-11-01
  • Resolved: 2020-04-14
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.
JDK 11 JDK 13 JDK 14 JDK 15
11.0.15-oracleFixed 13.0.7Fixed 14.0.2Fixed 15 b19Fixed
Related Reports
Duplicate :  
JDK-8242608 - java.exe does not start with special characters in parent directory names
Relates :  
JDK-8241461 - Can't start JVM when java path includes CJK chars and code-page is English
Relates :  
JDK-8242608 - java.exe does not start with special characters in parent directory names
Relates :  
JDK-8240197 - Cannot start JVM when $JAVA_HOME includes CJK characters
Relates :  
JDK-8191521 - handle long relative path specified in -Xbootclasspath/a on windows
Description
Java fails to start on Windows 10 with non-ASCII characters in the path if current regional format differs from the system locale.
(Settings | Time & Language | Language | Administrative language settings | Administrative tab | Language for non-Unicode programs | System locale: X)
(Settings | Time & Language | Regional format | Current format: Y)

For example, jdk15 fails if java path contains German characters and:

System locale: German (Germany)
Current format: English (Europe)
Region: Germany
Active code page: 850

> C:\qwertz-ßüöä\openjdk-15-ea+17_windows-x64\bin\java -version
Error occurred during initialization of VM
Failed setting boot class path.

Previous jdk versions work ok in this case:

> C:\qwertz-ßüöä\openjdk-11+28_windows-x64\bin\java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

> C:\qwertz-ßüöä\openjdk-13+33_windows-x64\bin\java -version
openjdk version "13" 2019-09-17
OpenJDK Runtime Environment (build 13+33)
OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing)

> C:\qwertz-ßüöä\openjdk-14+36_windows-x64\bin\java -version
openjdk version "14" 2020-03-17
OpenJDK Runtime Environment (build 14+36-1461)
OpenJDK 64-Bit Server VM (build 14+36-1461, mixed mode, sharing)

Jdk15 and jdk14 fail if java path contains Russian characters and:

System locale: Russian (Russia)
Current format: English (Europe)
Region: Russia
Active code page: 866

> C:\йцукен\openjdk-15-ea+17_windows-x64\bin\java -version
Error occurred during initialization of VM
Failed setting boot class path.

> C:\йцукен\openjdk-14+36_windows-x64\bin\java -version
Error occurred during initialization of VM
Failed setting boot class path.

Old jdk13 and jdk11 versions work ok:

> C:\йцукен\openjdk-11+28_windows-x64\bin\java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

> C:\йцукен\openjdk-13+33_windows-x64\bin\java -version
openjdk version "13" 2019-09-17
OpenJDK Runtime Environment (build 13+33)
OpenJDK 64-Bit Server VM (build 13+33, mixed mode, sharing)
Comments
Fix request (13u). I would like to backport the partial fix to jdk13u for parity with jdk11u. It's a partial fix related only to HotSpot. The scope of fixes is the same as for jdk11u. The reasons is the same. The original (partial) patch applied cleanly. Tested manually. This patch is applied after JDK-8240197 and it fixes the following scenario for example: System locale: Chinese (Simplified, China) Current format: English (United States) Active code page: 936 Before the patch: /cygdrive/y/projects/jdk13u-dev-fork/build/windows-x86_64-server-release_中文_/images/jdk/bin $ ./java -version Error occurred during initialization of VM Failed setting boot class path. After the patch: /cygdrive/y/projects/jdk13u-dev-fork/build/windows-x86_64-server-release_中文_/images/jdk/bin $ ./java -version openjdk version "13.0.7-internal" 2021-04-20 OpenJDK Runtime Environment (build 13.0.7-internal+0-adhoc.omikhaltsova.jdk13u-dev-fork) OpenJDK 64-Bit Server VM (build 13.0.7-internal+0-adhoc.omikhaltsova.jdk13u-dev-fork, mixed mode, sharing)
11-02-2021
[~ysuenaga] Thanks for the clarifications. We're all for reducing risk. OK, I'll approve.
05-06-2020
[~sgehwolf] I've received email from [~naoto] (jdk-updates Reviewer), but it wasn't delivered because he hadn't subscribed jdk-update-dev. He has been reviewed this backport patch. https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003234.html Vitaly's approach is good, but it is a big change to support UNC path / long path (beyond MAX_PATH) - it have to change to use wide char in many place. So I want to merge just this patch to hedge the risk.
04-06-2020
[~ysuenaga] Have you considered an approach suggested by Vitaly? Also the RFR hasn't been approved by an jdk-updates Reviewer yet. Please only add the label for approval once the patch has been reviewed. I'll remove the label for now to get it off the queue. Please add it back once the patch has been reviewed and/or the approach changes. Thanks!
04-06-2020
[~ysuenaga] Just a note from testing on our side. For jbr11 changing CP_THREAD_ACP to CP_ACP in os_windows.cpp was not enough to fix the issue. To make it work I also had to backport JDK-8232168 + JDK-8240725 to canonicalize_md.c and change CP_THREAD_ACP to CP_ACP there. And as production solution (while it is not yet fixed in OpenJDK11) we decided to use "JDK-8240197 + JDK-8232168 + JDK-8218547 + JDK-8240725 + CP_THREAD_ACP -> CP_ACP" for our fork of 11.
14-04-2020
Fix request for 11u: JVM fails to start on Windows with non-ASCII characters in the path if current regional format differs from the system locale. We need to convert char* to wchar_t* to support long path, so I used CP_THREAD_ACP in MultiByteToWideChar(). But we found CP_ACP works nicely rather than CP_THREAD_ACP. Using CP_THREAD_ACP was introduced in JDK-8240197 and JDK-8240725, however only JDK-8240197 has been backported to 11u. So I want to apply original bug to 11u partially. I've sent RFA to jdk-updates-dev: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/003002.html
14-04-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/5f5876adb88c User: ysuenaga Date: 2020-04-14 00:04:21 +0000
14-04-2020
I submitted the change to submit repo as a single fix. I will send review request after receiving the result from it. http://hg.openjdk.java.net/jdk/submit/rev/a506a478d3bc
10-04-2020
It's OK to have each backport different, and sometimes it has to be (for obvious reason). I think keeping it simple from the issue standpoint (less issue #s.) is worth than an extra code review for 11u. That will help someone trying to understand what has happened at a later time.
10-04-2020
JDK-8240197 has been backported to JDK 11, but JDK-8240725 haven't yet. If all fix is done in one (this) ticket, we need to create a patch for 11u and send review request again because we need to fix os_windows.cpp only for 11u. I think separating issue (e.g. subtask) makes easy to backport.
10-04-2020
The limitation is (implicitly) described in the spec for JNI_CreateJavaVM() (https://docs.oracle.com/en/java/javase/14/docs/specs/jni/invocation.html#jni_createjavavm): ``` char *optionString; /* the option as a string in the default platform encoding */ ``` This effectively limits the API to be incapable of supporting Unicode, like the *A version in Win32, thus results in unpredictable behavior if the system locale, which derives the JNI encoding, and the user locale mismatch. As to how to proceed with this issue, I don't see the reason to create a subtask. I would expect it to be fixed in JDK15 first, then create backports as needed.
10-04-2020
[~naoto] Where is this limitation described? If not so, I think we need to do it. I grep'ed jdk/jdk source with CP_THREAD_ACP, I got the result as below: ``` [ysuenaga@fc31 src]$ grep -nrw CP_THREAD_ACP * hotspot/os/windows/os_windows.cpp:4146: int unicode_path_len = MultiByteToWideChar(CP_THREAD_ACP, hotspot/os/windows/os_windows.cpp:4156: int result = MultiByteToWideChar(CP_THREAD_ACP, java.base/share/native/libzip/zip_util.c:139: int wfname_len = MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, java.base/share/native/libzip/zip_util.c:147: if (MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, java.base/windows/native/libjava/canonicalize_md.c:337: wpath_len = MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, java.base/windows/native/libjava/canonicalize_md.c:347: if (MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, java.base/windows/native/libjava/canonicalize_md.c:360: if (WideCharToMultiByte(CP_THREAD_ACP, 0, java.base/windows/native/libjli/java_md.c:507: unicode_path_len = MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_C HARS, java.base/windows/native/libjli/java_md.c:521: if (MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, jdk.incubator.jpackage/windows/native/libapplauncher/WindowsPlatform.cpp:407: count = MultiByteToWideChar(CP_THREAD_A CP, MB_ERR_INVALID_CHARS, jdk.incubator.jpackage/windows/native/libapplauncher/WindowsPlatform.cpp:412: result.length = MultiByteToWideChar (CP_THREAD_ACP, MB_ERR_INVALID_CHARS, ``` They have been changed by JDK-8240197 and JDK-8240725. Considering to backport the change (CP_THREAD_ACP -> CP_ACP) to JDK 11, I think it is better to separate them. Can we create subtasks under this issue for them? If it is ok, I will do so and will create a patch.
10-04-2020
JDK never "officially" supported the environment where the system locale and user locale disagree on Windows, although it works nicely in many cases. Having said that, the recommended approach in this issue is to use CP_ACP in codepage<->widechar conversion functions, as CP_THREAD_ACP is based on the user locale. The issue that the Japanese encoded pathname cannot be recognized under the English system locale has always been the limitation, which comes from the Invocation API not being able to support Unicode.
09-04-2020
[~ysuenaga] But that scenario doesn't work with an Oracle 1.8u152 from 2017 too, which just uses the Windows *A calls. c:\priv\jdk\1.8.0_152_64-йцукен\bin\java -version Error: opening registry key 'Software\JavaSoft\Java Runtime Environment' Error: could not find java.dll Error: Could not find Java SE Runtime Environment. versus >c:\priv\jdk\1.8.0_152_64\bin\java -version java version "1.8.0_152" Java(TM) SE Runtime Environment (build 1.8.0_152-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode) I have debugged this (for JDK 15) and it fails in the launcher, when getting the JRE home via GetModuleFileName(). The file name returned by this call already has question marks (0x3f) for the russian characters. So I don't think this can be supported and is no regression.
09-04-2020
Example of CP_ACP doesn't work is shown by Vitaly in above comment: ``` I also made a quick check and non of these builds were able to start in case system locale differs from characters encoding used in java path, like in JDK-8241461: System locale: English (US) Current format: English (US) Active code page: 437 > C:\йцукен\jbr-15-windows-x64-b146-cp_acp\bin\java -showversion Main Error: could not find java.dll Error: Could not find Java SE Runtime Environment. ``` JDK-8241461 is also example of this issue. It attempted to start JVM on the path which includes Japanese chars on English locale.
09-04-2020
[~ysuenaga} Can you provide an example where CP_ACP doesn't work? Please specify the system locale/Region and OEM codepage (output of chcp) of this case.
09-04-2020
[~vprovodin] Thank you for the report! Result of JBR 15 is interesting for me. CP_ACP does not work in all cases as I said - I think it is not the solution. As I said in above comment, it might be trade-off between long path support and path on non-ASCII chars support. I think we can approach as below: A. Describe release notes about this issue. Workaround is: - Do not deploy Java to the path which contains non-ASCII char(s) that OS is not configured. - Create symbolic link with ASCII chars (MKLINK) B. Replace CP_THREAD_ACP to CP_ACP to mitigate the issue. But it cannot fix all cases, so we need to describe the issue to release note. C. Do not use wstring, and describe the limitation of path length to release notes. I give +1 to A. because all of them could not fix the issue completely. B. can mitigate the issue, but I disagree it. JVM is started not only `java` but also JNI call such as commons-daemon. JNI apps maybe set different locale. If most of users would not deploy Java which path does not exceed MAX_PATH, we can take C. as an action. (For example, "C:\Program Files\java\jdk-11.0.6" does not exceed MAX_PATH) Also We might be able to add option for long path like *W functions on Windows (it is just idea).
09-04-2020
[~ysuenaga] I've applied your patch and as expected it doesn't work: C:\priv\openjdk\dbg\images\jdk-qwertz-ßüöä-0\bin\java.exe -version # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=c:/priv/hg/openjdk/src/hotspot/share/classfile/classLoader.cpp:666 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (c:/priv/hg/openjdk/src/hotspot/share/classfile/classLoader.cpp:666), pid=1596, tid=11168 # assert(new_entry != 0LL && new_entry->is_modules_image()) failed: No java runtime image present # # JRE version: (15.0) (slowdebug build ) # Java VM: OpenJDK 64-Bit Server VM (slowdebug 15-internal+0-adhoc.ralf.openjdk, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64) # No core dump will be written. Failed to create minidump file (0x5). # # An error report file with more information is saved as: # C:\Users\d039344\AppData\Local\Temp\\hs_err_pid1596.log This is caused by the failing canonocalize method. I would guess that Vitaly hasn't seen this error, since he build a version 11, which doesn't includes your changes to the JDK_Canonicalize() method.
09-04-2020
[~rschmelter] CP_ACP means to use the system default Windows ANSI code page, it is described in the document of MultiByteToWideChar() https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar So I guess it still would not work on default locale is different from path chars such as JDK-8241461 (Japanese chars on English locale) even if we change to CP_ACP. You propose to change MultiByteToWideChar() call in JDK_Canonicalize(), but I wonder why it would work. My proposal (remove-wstring.patch) has been confirmed to work in this issue even if it does not changed this call. It is supposed to be failed if we need to change JDK Canonicalize(). I understood Unicode version (*W) functions expand limits for file name length. They are needed for JDK-8191521. It might be trade-off between long path support and path on non-ASCII chars support.
09-04-2020
[~rschmelter] [~ysuenaga] Yes, I've experimented with 11 codebase before. Jbr11.0.6 includes fixes for JDK-8191521 and JDK-8240197, but misses "canonicalize" fixes, like JDK-8232168, JDK-8234185, JDK-8240725, JDK-8218547, etc. which go in a bunch one after another. Probably that is why we had no luck with just changing CP_THREAD_ACP to CP_ACP. Today I've tested three following builds: 1) jbr11 + JDK-8232168 + JDK-8240725 (canonicalize_md.c update only) + CP_THREAD_ACP -> CP_ACP 2) clean jbr15 + CP_THREAD_ACP -> CP_ACP 3) clean jbr15 + remove-wstring.patch Changing CP_THREAD_ACP to CP_ACP helped both jbr11 (1) and jbr15 (2) to eliminate dependency on regional format. And both jbrs work for the configurations from the ticket description which were failing before: System locale: German (Germany) / Russian (Russia) Current format: English (Europe) Active code page: 850 / 866 > C:\йцукен\jbr-11_0_6-windows-x64-b765.35-cp_acp\bin\java -showversion Main openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment (build 11.0.6+8-b765.35) OpenJDK 64-Bit Server VM (build 11.0.6+8-b765.35, mixed mode) > C:\йцукен\jbr-15-windows-x64-b146-cp_acp\bin\java -showversion Main openjdk version "15" 2020-09-15 OpenJDK Runtime Environment (build 15+10-b146) OpenJDK 64-Bit Server VM (build 15+10-b146, mixed mode) Unfortunately jbr15+remove-wstring.patch (3) failed to run in this system configurations for me (although it works with Japanese system locale): > C:\йцукен\jbr-15-windows-x64-b147_remove\bin\java -showversion Main Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object I also made a quick check and non of these builds were able to start in case system locale differs from characters encoding used in java path, like in JDK-8241461: System locale: English (US) Current format: English (US) Active code page: 437 > C:\йцукен\jbr-15-windows-x64-b146-cp_acp\bin\java -showversion Main Error: could not find java.dll Error: Could not find Java SE Runtime Environment. Using Unicode language support also did not work: System locale: English (US), Beta: Use Unicode UTF-8 for worldwide language support Current format: English (US) Active code page: 65001 C:\йцукен\jbr-15-windows-x64-b146-cp_acp\bin\java -showversion Main openjdk version "15" 2020-09-15 OpenJDK Runtime Environment (build 15+10-b146) OpenJDK 64-Bit Server VM (build 15+10-b146, mixed mode) Exception in thread "main" java.lang.UnsatisfiedLinkError: no awt in system library path: C:\йцукен\jbr-15-windows-x64-b146-cp_acp\bin at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2396) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:809) at java.base/java.lang.System.loadLibrary(System.java:1889) at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1380) at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:1378) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at java.desktop/java.awt.Toolkit.loadLibraries(Toolkit.java:1377) at java.desktop/java.awt.Toolkit.<clinit>(Toolkit.java:1410) at java.desktop/java.awt.EventQueue.invokeLater(EventQueue.java:1312) at java.desktop/javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1421) Hope this helps. I think for now it is enough to make jvm work as before (before JDK-8191521 fix), eliminate this dependency on regional format, but have system locale in sync with characters used in java home path. It would be really great if solution for this issue could be entirely backported to jdk11.
09-04-2020
[~vprovodin] Have you changed both the convert_to_unicode() and the JDK_Canonicalize() method in libjava. I first only changed the first one, but then you fail the canonicalization. And after changing both it worked for me. Here is the diff: diff -r db8ac4690d6a src/hotspot/os/windows/os_windows.cpp --- a/src/hotspot/os/windows/os_windows.cpp Wed Apr 08 15:00:39 2020 +0200 +++ b/src/hotspot/os/windows/os_windows.cpp Wed Apr 08 19:16:28 2020 +0200 @@ -4143,7 +4143,7 @@ static errno_t convert_to_unicode(char const* char_path, LPWSTR* unicode_path) { // Get required buffer size to convert to Unicode - int unicode_path_len = MultiByteToWideChar(CP_THREAD_ACP, + int unicode_path_len = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS, char_path, -1, NULL, 0); @@ -4153,7 +4153,7 @@ *unicode_path = NEW_C_HEAP_ARRAY(WCHAR, unicode_path_len, mtInternal); - int result = MultiByteToWideChar(CP_THREAD_ACP, + int result = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS, char_path, -1, *unicode_path, unicode_path_len); diff -r db8ac4690d6a src/java.base/windows/native/libjava/canonicalize_md.c --- a/src/java.base/windows/native/libjava/canonicalize_md.c Wed Apr 08 15:00:39 2020 +0200 +++ b/src/java.base/windows/native/libjava/canonicalize_md.c Wed Apr 08 19:16:28 2020 +0200 @@ -334,7 +334,7 @@ int ret = -1; /* Get required buffer size to convert to Unicode */ - wpath_len = MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, + wpath_len = MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS, orig, -1, NULL, 0); if (wpath_len == 0) { goto finish; @@ -344,7 +344,7 @@ goto finish; } - if (MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, + if (MultiByteToWideChar(CP_ACP, MB_ERR_INVALID_CHARS, orig, -1, wpath, wpath_len) == 0) { goto finish; } @@ -357,7 +357,7 @@ goto finish; } - if (WideCharToMultiByte(CP_THREAD_ACP, 0, + if (WideCharToMultiByte(CP_ACP, 0, wresult, -1, out, len, NULL, NULL) == 0) { goto finish; }
08-04-2020
[~ysuenaga] I've applied remove-wstring.patch (along with the JDK-8240197 fix) to JetBrains Runtime (jbr) 11.0.6 and the patch seems to fix the issue with jvm start if the current regional format differs from the system locale. I'm still waiting some additional info from my colleagues, but the patched jvm works for me for the configurations from the ticket description which were failing before: System locale: German (Germany) Current format: English (Europe) Active code page: 850 > C:\qwertz-ßüöä\jbr-11_0_6-windows-x64-b765.31\bin\java -version openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment (build 11.0.6+8-b765.31) OpenJDK 64-Bit Server VM (build 11.0.6+8-b765.31, mixed mode) System locale: Russian (Russia) Current format: English (Europe) Active code page: 866 > C:\йцукен\jbr-11_0_6-windows-x64-b765.31\bin\java -version openjdk version "11.0.6" 2020-01-14 OpenJDK Runtime Environment (build 11.0.6+8-b765.31) OpenJDK 64-Bit Server VM (build 11.0.6+8-b765.31, mixed mode) [~rschmelter] We've actually thought about changing CP_THREAD_ACP to CP_ACP and tried it after applying JDK-8240197 fix to jbr, but for some reason this change was not enough to eliminate the dependency on the current regional format.
08-04-2020
Why do you think that? Is there any Microsoft documentation which supports your view? I haven't been able to find one. See, the NT kernel is Unicode, so every Win32 call taking a char* must convert to Unicode. So it should be possible to do this, right? And the documentation says the *A functions use the Ansi Code Page by default. Why should this not work? And the code uses Unicode since otherwise path > 255 chars are not supported.
08-04-2020
I don't think CP_ACP is the solution because in case of JDK-8241461, `java` could not start on Japanese chars when default codepage is set to English. I think we can avoid these problem if we do not convert to unicode.
08-04-2020
I've reproduced the problem. The encoding of the characters you get for the paths is CP 1252 (a ISO latin-1 variant). When you query which code page would be used for the CP_* constants you get this: CP_ACP: CP1252 (the correct one) CP_THREAD_ACP: CP 65001 (a.k.a UTF-8) CP_OEMCP: CP 850 And since the code uses CP_THREAD_ACP, it tries to convert characters which are really CP1252 as UTF-8. The solution is to just use CP_ACP, which does exactly what you need (both in the convert_to_unicode method and the JDK_Canonicalize method). CP_ACP is what all the *A file functions would use. And chcp only changes the OEM code page, which is used for console operations. It has not the same effect as setting the system locale.
08-04-2020
remove-wstring.patch can be applied after the change of JDK-8240197. It has been backported to 11.0.8 (JDK-8240823).
08-04-2020
I'm going to test the patch by applying it to JetBrains Runtime 11.0.6 (which is a fork of OpenJDK)
08-04-2020
remove-wstring.patch works fine on my laptop (Japanese locale). Someone can help to test this patch? [~rschmelter] , why do you use wchar_t* in JDK-8191521? If it is no problem to use char* instead of wchar_t*, and remove_wstring.patch works fine on other locales, I will send review request to hotspot-runtime-dev.
08-04-2020
I think this issue is same as others including JDK-8241461. I guess it failed at MultiByteToWideChar(). I use this API in JDK-8240197 because wide_abs_unc_path() which is introduced in JDK-8191521 expects to return UNC path as wide string. But we maybe able to use char* if we change the API which is passed the result in caller from *W to *A (char* version). I think it is worth to try. If you (or someone who encounter same problem) can help to check my patch, I will make it. If it failed or difficult to fix, we can describe it to release notes.
08-04-2020
This still looks like the same basic problem as JDK-8241461 to me. [~ysuenaga] and [~rschmelter] as you have both worked on these unicode path issues can you please investigate? Have we introduced a general regression by "fixing" a different UNC/path issue? Is this unsolvable in general and so needs to be documented in the release notes?
08-04-2020
ILW = HLM = P3
07-04-2020
In this issue system locale (German/Russian) corresponds to the characters encoding used in java path (German/Russian), but current format differs (English). In JDK-8241461 system locale (English) was different from the characters encoding used in java path (Japanese). Is it expected that different regional format cause jvm initialization fail? It seems to work in previous releases. If use the same regional format as the system locale, then java starts ok, for example: System locale: German (Germany) Current format: German (Germany) Region: Germany Active code page: 850 > C:\qwertz-ßüöä\openjdk-15-ea+17_windows-x64\bin\java -version openjdk version "15-ea" 2020-09-15 OpenJDK Runtime Environment (build 15-ea+17-717) OpenJDK 64-Bit Server VM (build 15-ea+17-717, mixed mode, sharing)
07-04-2020
Isn't this the same issue reported in JDK-8241461?
07-04-2020