Temurin-build: Chinesische Zeichen im Pfad zu java.exe verursachten den Fehler "Native Bibliothek kann nicht geladen werden"

Sieht aus wie bei koreanischen Schriftzeichen

Von einem Benutzer in meiner App gemeldet, jlink build mit jdk-11.0.6 + 10

Das Startskript im Bild

<strong i="10">@echo</strong> off
set DIR="%~dp0"
set JAVA_EXEC="%DIR:"=%\java"
%JAVA_EXEC%  -p "%~dp0/../app" -m com.pmm.ParadoxosGameModManager/com.pmm.ParadoxosGameModManager.ModManager  %*

Bearbeiten: Auch mit 11.0.5 getestet, bestätigen Sie, dass es funktioniert

@ himawari-san Kannst du bitte die 11.0.6 von adoptopenjdk.net/upstream.html ausprobieren?

@ Karianna Ich habe den gleichen Fehler.
Danke für deine Unterstützung.

Ich denke, es ist ein Fehler im Upstream. Ich habe dieses Problem in der aktuellen jdk / jdk-Quelle bestätigt. Es würde auf jedem Pfad auftreten, der CJK-Zeichen enthält.

Ich kann es mit dem Patch wie folgt beheben, daher möchte ich eine Überprüfungsanforderung für hotspot-runtime-dev in OpenJDK senden. Haben Sie jemals für die OpenJDK-Community gearbeitet? Wenn nicht, werde ich es bei JBS einreichen.

diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp
--- a/src/hotspot/os/windows/os_windows.cpp
+++ b/src/hotspot/os/windows/os_windows.cpp
@@ -4207,14 +4207,16 @@
     size_t prefix_len = wcslen(prefix);
     size_t full_path_size = is_abs ? 1 + buf_len : JVM_MAXPATHLEN;
     size_t result_size = prefix_len + full_path_size - prefix_off;
-    result = (wchar_t*) os::malloc(sizeof(wchar_t) * (additional_space + result_size), mtInternal);
+    size_t result_buffer_size = sizeof(wchar_t) * (additional_space + result_size);
+    result = (wchar_t*) os::malloc(result_buffer_size, mtInternal);

     if (result == NULL) {
       err = ENOMEM;
     } else {
-      size_t converted_chars;
+      ZeroMemory(result, result_buffer_size);
       wchar_t* path_start = result + prefix_len - prefix_off;
-      err = ::mbstowcs_s(&converted_chars, path_start, buf_len + 1, buf, buf_len);
+      int win32_ret = MultiByteToWideChar(CP_THREAD_ACP, MB_ERR_INVALID_CHARS, buf, (int)buf_len, path_start, (int)(buf_len + 1));
+      err = (win32_ret == 0) ? EINVAL : ERROR_SUCCESS;

       if ((err == ERROR_SUCCESS) && needs_fullpath) {
         wchar_t* tmp = (wchar_t*) os::malloc(sizeof(wchar_t) * full_path_size, mtInternal);

@YaSuenag Nein, habe ich nicht. Ich habe Ihre Hilfe geschätzt.

Ich habe dieses Problem an JBS gemeldet und eine Überprüfungsanforderung an hotspot-runtime-dev gesendet.

https://bugs.openjdk.java.net/browse/JDK-8240197
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-February/038330.html

@YaSuenag danke für deinen Beitrag!
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html

Ich habe dieses Problem in jdk / jdk behoben und auch nach jdk / jdk11u-dev zurückportiert . Es wird in 11.0.8 ausgeliefert. Ich denke, Sie können AdoptOpenJDK 11 seit 11.0.8 auf dem CJK-Pfad verwenden.