将含原生库的Applet JAR作Maven依赖时触发UnsatisfiedLinkError

你遇到的UnsatisfiedLinkError和JAR签名、依赖权限无直接关联，本质是原Java WebStart自动处理原生库的逻辑在本地普通应用中缺失，以下逐个回应你的疑问并给出修复方案：

项目依赖的本地文件访问权限问题 #

• 不存在“项目依赖本身不具备本地文件访问权限”的概念。将原生库JAR配置为项目依赖后，类加载器读取JAR内资源的权限完全继承自当前运行Java进程的系统权限，JAR签名仅在原Applet/WebStart沙箱环境下生效，改造为本地应用后沙箱限制已自动失效，签名不影响本地文件读取。

Java进程的目录访问权限问题 #

• 不需要给Java进程开放特殊目录权限，但要满足两个系统层面的加载前提：
  • 运行Java进程的系统用户，对你配置的/Users/me/java/apps目录、以及目录下的dylib文件持有读+执行权限，可通过chmod 755 /Users/me/java/apps/lib<库名>.dylib修正权限
  • MacOS 10.15及以上版本对下载/解压得到的二进制文件默认加quarantine隔离标记，未清除标记的dylib会被系统直接拦截加载，执行xattr -d com.apple.quarantine /Users/me/java/apps/lib<库名>.dylib即可清除标记
• 很多时候你以为java.library.path配置生效了，实际IDE、启动脚本会覆盖该参数，启动时先打印System.getProperty("java.library.path")确认目标目录确实在JVM扫描列表里。

存放原生库的JAR命名规则问题 #

• 本地普通Java应用中，存放原生库的JAR没有强制命名规则，JVM不会自动从依赖JAR中提取原生库加载。System.loadLibrary方法只会扫描文件系统上java.library.path指定的目录，不会读取JAR包内部的文件。原JNLP启动时是Java WebStart插件自动完成了“按操作系统匹配原生库JAR→提取库文件到临时目录→把临时目录加入加载路径”的全流程，你改造为本地应用后这部分逻辑缺失，是报错的核心原因。

1. 放弃仅配置java.library.path的调试方式，在应用启动阶段实现原生库自动提取逻辑：从classpath下的原生库JAR中，匹配当前操作系统（MacOS取dylib、Windows取dll、Linux取so）、当前CPU架构的库文件，释放到应用自身可控的固定目录（比如应用安装目录下的native子目录）
2. 库文件释放完成后，先执行权限修正、MacOS隔离标记清除操作，再直接调用System.load(库文件的绝对路径)加载，绕开java.library.path的扫描逻辑，彻底避免路径配置错误
3. 提前校验dylib的架构和当前JDK架构一致：M系列芯片设备上运行aarch64架构的JDK时，不能加载x86_64编译的dylib，x86_64架构的JDK也无法加载aarch64的dylib，架构不匹配时同样会抛出找不到库的错误

补充说明：你使用的NanoHTTPD是同进程内的Web服务框架，不会干预JVM的原生库加载逻辑，不需要针对框架做特殊适配。

内容的提问来源于stack exchange，提问作者jonasmylesx