长话短说：我有一个可执行jar，它调用依赖于lib.dll的jni.dll。我得到了非常可怕的UnsatisfiedLinkError。
这个答案非常接近，但根据我的经验，它未能解决问题。即使在java.library.path中指定了dll所在的文件夹，它也不会工作。我还必须更改WindowsPATH环境变量。事实上，Windows上默认的java.library.path似乎是PATH。
有什么"漂亮"的方法可以解决这个问题吗？我想为Windows构建一个安装程序，我想知道如何处理这个问题，这样最终用户就不必做任何手动工作。
编辑：
我实现了以下内容：该应用程序附带了一个名为"native_libs"的文件夹，该文件夹为所有受支持的体系结构提供了动态库。结构如下：
/
+- native_libs/
+- windows/
| +- x86/
| | +- ...
| +- x64/
| +- ...
|
+- linux/
| +- x86/
| | +- ...
| +- x64/
| +- ...
|
+- libs/
+- ...
在运行时，当应用程序初始化时，会检测到正确的JRE体系结构和系统操作系统，并将正确的库文件复制到libs/文件夹中。java.library.path也在运行时使用常见的破解进行设置。最后，使用本机启动器设置windows的PATH环境变量。
还有改进的余地吗？也许将dll复制到与jar文件相同的目录中会否定设置java.library.path和PATH变量的需要？我还需要研究用System.load()加载dll，这将消除复制文件的需要。
java.library.path指定System.loadLibrary()查找动态库文件的目录。如果更改代码中的java.library.path系统属性，则不会有任何效果。有一些技巧可以让Java"忘记"初始值并重新评估java.library.path系统属性的内容。
但是，依赖库不是由Java加载的，而是由Windows加载的。Windows不关心java.library.path，它只关心PATH环境变量。您唯一的选择是针对Java进程调整PATH。例如，如果从批处理文件启动它，请在java调用之前更改PATH环境变量。
最简单的解决方案是确保所有.dll都在'.'中执行时。
如果问题是操作系统找不到依赖库，那么在加载主库之前，您是否尝试过通过System.loadLibrary()加载它？
将jni.dll所依赖的dll放在您的"当前工作目录"中，在运行时检查此System.getProperty("user.dir")以了解您的"目前工作目录"是什么