Temurin-build: Les caractères chinois dans le chemin de java.exe ont provoqué l'erreur «Impossible de charger la bibliothèque native»

On dirait que c'est la même chose avec les caractères coréens

Rapporté par un utilisateur sur mon application, jlink build avec jdk-11.0.6 + 10

Le script de lancement dans l'image

<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  %*

Edit: également testé avec 11.0.5, confirmez que cela fonctionne

@ himawari-san Pouvez-vous essayer le 11.0.6 de adoptopenjdk.net/upstream.html s'il vous plaît?

@karianna J'ai eu la même erreur.
Merci pour votre aide.

Je pense que c'est un bug en amont. J'ai confirmé ce problème sur la source jdk / jdk actuelle. Cela se produirait sur n'importe quel chemin contenant des caractères CJK.

Je peux le réparer avec le correctif comme ci-dessous, donc je veux envoyer une demande de révision pour hotspot-runtime-dev dans OpenJDK. Avez-vous déjà travaillé pour cela dans la communauté OpenJDK? Sinon, je le déposerai sur JBS.

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 Non, je ne l'ai pas fait. J'ai apprécié votre aide.

J'ai signalé ce problème à JBS et envoyé une demande d'examen à hotspot-runtime-dev.

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

@YaSuenag merci pour votre contribution!
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-March/038397.html

J'ai corrigé ce problème dans jdk / jdk , et également rétroporté vers jdk / jdk11u-dev . Il sera expédié en 11.0.8. Je suppose que vous pouvez utiliser AdoptOpenJDK 11 sur le chemin CJK depuis 11.0.8.