Azul与Liberica JDK中JavaNativeFoundation.framework缺失主版本结构，如何让Java正常加载该框架？

问题背景 #

在M1 ARM架构Mac上使用Azul Zulu或Liberica JVM时，发现JavaNativeFoundation.framework没有遵循OS X传统的Versions/A目录结构，库文件直接放在框架顶层目录，导致运行依赖JNI的程序时出现加载错误：

[java] AquaNativeSupport: Unable to load library libvaqua.dylib: /private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib: dlopen(/private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib, 0x0001): Library not loaded: @rpath/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
[java] Referenced from: /private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib
[java] Reason: tried: '/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/server/./JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file), '/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/server/../JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file), '/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/bin/./JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file), '/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/bin/../lib/JavaNativeFoundation.framework/Versions/A/Java

1. 为何Azul/Zulu与Liberica的JavaNativeFoundation.framework缺失Versions版本结构？ #

这主要是厂商打包策略和适配简化的结果：

• 传统OS X框架的Versions目录是为了支持多版本库共存，方便系统或应用切换不同版本的框架文件。但对于JVM来说，每个JDK实例都是独立的，同一时间只会使用当前JDK下的框架，厂商认为不需要多版本支持，因此简化了目录结构，直接将库文件放在顶层。
• 另外，这些厂商在适配M1 ARM架构时，可能优先保证JNI核心功能可用，而没有严格遵循OS X的框架标准目录结构——毕竟JVM自身的JNI调用逻辑可能已经适配了这种简化结构，只是和Vaqua这类依赖传统框架路径的第三方库产生了冲突。

2. 无需手动修改目录的兼容方案 #

除了手动创建软链接的方式，还有以下几种更优雅的解决方案：

方案一：修改依赖库的rpath引用

使用install_name_tool工具修改libvaqua.dylib中对JavaNativeFoundation的引用路径，把指向Versions/A的路径改成直接指向顶层库文件：

install_name_tool -change "@rpath/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation" "@rpath/JavaNativeFoundation.framework/JavaNativeFoundation" /path/to/your/libvaqua.dylib

这个操作会直接修改库文件的链接信息，使其适配简化后的框架结构。

方案二：设置动态链接器环境变量

在启动Java程序前，设置DYLD_FRAMEWORK_PATH环境变量，指定框架所在目录，让动态链接器优先从该路径加载框架：

export DYLD_FRAMEWORK_PATH=/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib
java -jar your-app.jar

如果是通过IDE运行，需要在IDE的环境变量配置中添加这个变量。

方案三：升级到最新版本的JVM

部分厂商已经在后续版本中修复了这个目录结构问题，比如Azul Zulu 17+或Liberica的较新版本，可能已经默认包含了Versions/A目录和对应的软链接。建议检查并升级到最新的ARM兼容JDK版本，从根源上解决问题。

方案四：指定JVM系统属性

尝试通过JVM系统属性指定本地库路径，强制加载顶层的框架文件：

java -Djava.library.path=/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib -Dapple.awt.nativeLibraryPath=/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib -jar your-app.jar

这个方法需要测试，因为java.library.path主要针对普通.dylib文件，但部分AWT相关的JNI调用可能会识别这个路径。

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