Problem running in user account when username contains utf characters

[TorstenKarusseit]

Here is a simple test program (for jna 3.5.2):

import com.sun.jna.platform.win32.Kernel32Util;
public class Test
{
    public static void main(String[] args)
    {
        String s = Kernel32Util.getComputerName();
        return;
    }
}

When I test it on win7 account цц (2 cyrillic characters), I get the following exception:

Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\??\AppData\Local\Temp\jna1644595665224573683.dll: Can't find dependent libraries
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1928)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1825)
    at java.lang.Runtime.load0(Runtime.java:792)
    at java.lang.System.load(System.java:1059)
    at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:752)
    at com.sun.jna.Native.loadNativeLibrary(Native.java:737)
    at com.sun.jna.Native.<clinit>(Native.java:129)
    at com.sun.jna.Pointer.<clinit>(Pointer.java:42)
    at com.sun.jna.platform.win32.WinBase.<clinit>(WinBase.java:35)
    at com.sun.jna.platform.win32.Kernel32Util.getComputerName(Kernel32Util.java:41)
    at Test.main(Test.java:7)

When I test it on win7 account xx (2 'normal' characters), all goes fine.
This is heavy if you want to ship to russia or the most places in the world.
What may I do with this ?

[twall]

See issue #124

While System.load seems to fail to properly accommodate the unicode path, it's not alone. dependency walker will also fail to open a file if it has unicode characters in the path (not necessarily the filename, but its path). Any suggestions or workarounds are welcome.

[twall]

Nominally the workaround is to install jnidispatch.dll somewhere on PATH where it can be loaded, or set java.io.tmpdir or jna.tmpdir to a path without unicode characters.

[twall]

This is likely a JVM issue. Try running with a different JVM if possible (IBM's J9 does not exhibit this behavior). I have filed a bug for this (no reference number yet) against Oracle's 1.6/1.7 JDK.

[epot]

Hello,

We encounter the exact same issue and are kind of stuck. Do you have the oracle issue reference by any chance ?

Cheers,
Emmanuel

[matthiasblaesing]

The problem is tracked by:

https://bugs.openjdk.java.net/browse/JDK-8017274

I was able to reproduce this on Oracle JDK 8 on windows 10.

[eirikbakke]

I encountered this problem while trying to get the NetBeans IDE to work in similar situations (various things in NetBeans use JNA, including FlatLAF).

The problem can now be avoided by enabling "Beta: Use Unicode UTF-8 for worldwide language support" in the Region/Administrative/Change System Locale control panel option, and using a recent version of Java (where https://bugs.openjdk.org/browse/JDK-8272352 is fixed or backported).

(In the NetBeans case, the need to adjust control panel options is avoided by specifying UTF-8 as the activeCodePage in the launcher EXE file's application manifest, but that won't be an option when just running java.exe directly.)

[BullyWiiPlaza]

It's also good to know that another JDK which fixes the problem is e.g. OpenJDK 19 or Oracle JDK 19.
I still ran into this bug with OpenJDK 17 though.