JNA 加载失败，UnsatisfiedLinkError，“拒绝访问”

Question

有几个类似的问题，但我担心我的问题不同到足以区分。 我在 Windows 10 64 位，使用 Eclipse 4.11 和 OpenJDK 11，并且没有使用管理员帐户。

当我在内部项目上运行我们的 JUnit 5 测试套件时，出现异常：

java.lang.UnsatisfiedLinkError: C:\Users\myUserName\AppData\Local\Temp\jna-762579935\jna18359705168434975905.dll: Access is denied
    at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
    at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430)
    at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487)
    at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
    at java.base/java.lang.Runtime.load0(Runtime.java:767)
    at java.base/java.lang.System.load(System.java:1831)
    at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
    at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
    at com.sun.jna.Native.<clinit>(Native.java:195)
    at org.stuff.injury.orca.jna.OrcaJNAWrapper.<clinit>(OrcaJNAWrapper.java:21)
    at org.stuff.injury.orca.OrcaLibraryTest.<clinit>(OrcaLibraryTest.java:21)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:628)
    at org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:117)
    at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.lambda$invokeBeforeAllMethods$9(ClassTestDescriptor.java:376)
    at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
    at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.invokeBeforeAllMethods(ClassTestDescriptor.java:375)
    at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.before(ClassTestDescriptor.java:201)
    at org.junit.jupiter.engine.descriptor.ClassTestDescriptor.before(ClassTestDescriptor.java:77)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:132)
    at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
    at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
    at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
    at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
    at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
    at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
    at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
    at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
    at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
    at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
    at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:229)
    at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:197)
    at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:211)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:191)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:137)
    at org.eclipse.jdt.internal.junit5.runner.JUnit5TestReference.run(JUnit5TestReference.java:89)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)

设置断点后，我可以看到这个 DLL 就在那里，我可以复制（读取）和重命名（不是完全写权限，但仍然）文件。 它不是空的，所以 JVM 能够写入它。

附加信息：我发现了一些旨在帮助调试此类事情的设置，“jna.debug_load”和“jna.debug_load.jna”。 他们的输出并不是那么有启发性，尽管它确实表明它至少正在尝试正确的 DLL：

May 23, 2019 10:58:34 AM com.sun.jna.Native loadNativeDispatchLibrary
INFO: Looking in C:\Users\user.name\AppData\Local\Temp\jnidispatch.dll
May 23, 2019 10:58:34 AM com.sun.jna.Native loadNativeDispatchLibrary
INFO: Trying C:\Users\user.name\AppData\Local\Temp\jnidispatch.dll
May 23, 2019 10:59:18 AM com.sun.jna.Native extractFromResourcePath
INFO: Looking in classpath from jdk.internal.loader.ClassLoaders$AppClassLoader@2aae9190 for /com/sun/jna/win32-x86-64/jnidispatch.dll
May 23, 2019 10:59:18 AM com.sun.jna.Native extractFromResourcePath
INFO: Found library resource at jar:file:/D:/Tools/Java-JDK/openjdk-11+28_windows-x64_bin/jdk-11/lib/jna-5.3.1.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll
May 23, 2019 10:59:18 AM com.sun.jna.Native extractFromResourcePath
INFO: Extracting library to C:\Users\user.name\AppData\Local\Temp\jna-762579935\jna7239609079883644065.dll
May 23, 2019 10:59:18 AM com.sun.jna.Native loadNativeDispatchLibraryFromClasspath
INFO: Trying C:\Users\user.name\AppData\Local\Temp\jna-762579935\jna7239609079883644065.dll

所以它肯定是从适当的资源中提取 DLL。 如果它是 32 位 DLL 而不是 64 位 DLL，我预计会出现不同的错误，尽管如果这是问题所在，这几乎不是我第一次遇到误导性错误消息。

Answer 1

尤里卡！ 当我尝试“jna.boot.library.path”设置时，我仍然在我自己的 Temp 目录中。 看起来我的系统不允许从临时文件夹加载 DLL。 我确实在一台相对受限的计算机上运行，​​这似乎是人们可能采取的一种合理的预防措施。

所以： 提取 DLL，将其移动到不在我的用户帐户临时目录下的文件夹中，一切都很好......实际上并非如此，我只是收到一个新错误，但至少这个错误已解决。

Answer 2

您可以重新定义 java 将临时文件存储到不受限制的文件夹的位置：

-Djava.io.tmpdir=D:\\\\javatmpdir

为我工作，但必须手动创建文件夹