1. 项目概述当Java需要调用“本地力量”在Java开发中我们绝大多数时候都享受着“一次编写到处运行”的便利但总有一些场景Java本身的力量显得捉襟见肘。比如你需要调用一个用C编写的高性能数学计算库或者操作一个只有Windows API才能访问的特定硬件设备又或者复用一套历史遗留的、用C语言编写的核心业务逻辑。这时JNIJava Native Interface就成了连接Java世界与本地Native代码世界的桥梁。这个项目标题“Java JNI例子--创建DLL、项目导入DLL、IDEA配置JNI、JNI调用DLL该DLL同时依赖第三方DLL”清晰地勾勒出了一条从零开始、完整且具有一定复杂度的JNI实战路径。它不仅仅是一个简单的“Hello World”示例而是触及了企业级应用开发中常见的痛点如何封装本地代码为DLL、如何在现代IDEIntelliJ IDEA中优雅地集成与调试、以及如何处理更复杂的依赖链你的DLL还依赖另一个第三方DLL。很多教程只讲到第一步当你的本地库本身还依赖其他库时程序运行时就会抛出令人头疼的“UnsatisfiedLinkError”或根本找不到依赖库的错误而本文将带你彻底解决这些问题。简单来说我们将完成这样一件事用C/C编写一个核心函数将其编译成动态链接库DLL并且让这个DLL调用另一个现成的第三方DLL例如一个加密库或图像处理库的功能最后在Java程序中通过JNI调用我们自己的DLL从而间接使用第三方DLL的能力。整个过程涉及Java、C/C、Windows开发环境以及IDEA配置是一套完整的全栈式本地接口开发体验。2. 核心思路与工具选型解析在动手写代码之前理清整个流程的技术选型和背后逻辑至关重要。这能帮助你在遇到问题时知道该从哪个环节去排查。2.1 为什么是JNI而不是JNA或JNRJava调用本地代码除了JNI还有JNAJava Native Access和JNRJava Native Runtime等更“现代化”的封装。它们号称无需编写C代码直接使用Java接口映射。那为什么我们这个项目还是选择从JNI入手根本原因在于控制力和性能。JNI是Java官方标准它提供了最底层、最直接的控制。当你的本地库本身还依赖其他复杂的三方库时JNI允许你在C/C层面对这些依赖的加载、初始化和错误处理进行精细化管理。而JNA/JNR在跨平台和易用性上更优但对于复杂依赖链和需要极致性能的场景其通过反射实现的调用开销和依赖解析的“黑盒”特性可能会成为调试的噩梦。从学习角度而言掌握JNI能让你真正理解Java虚拟机与操作系统交互的机制这是理解JNA/JNR等上层封装的基础。因此处理“DLL依赖第三方DLL”这种复杂情况从JNI开始是更稳妥、更透彻的选择。2.2 开发环境与工具链确定工欲善其事必先利其器。以下是经过实战检验的工具组合Java开发环境JDK 8或以上推荐JDK 11 LTS。确保java和javac命令可用。关键点在于你使用的JDK版本需要与后续编译DLL时使用的编译器在架构上匹配例如都是64位。集成开发环境IDEIntelliJ IDEA Community或Ultimate版。我们将充分利用IDEA对Native开发的支持来简化流程。C/C编译环境这是核心。在Windows上我们选择MinGW-w64或Visual Studio Build Tools。MinGW-w64更轻量生成纯正的GCC风格DLL与Java的亲和性很好。对于不涉及复杂Windows SDK特性的项目它是首选。Visual Studio Build Tools功能强大特别是如果你的第三方DLL本身就是用VC编译的使用同系列的编译器可以最大程度避免运行时库如msvcrXXX.dll的冲突。本项目为了模拟最常见的企业环境我们选择使用Visual Studio 2019/2022的Build Tools只需要安装“使用C的桌面开发”工作负载。辅助工具Dependency Walker或Visual Studio自带的dumpbin用于分析DLL的导出函数和依赖关系是调试“找不到依赖”问题的神器。文本编辑器如VS Code或Notepad用于编辑C/C头文件和源文件。2.3 项目整体流程设计整个项目将遵循一个清晰的流水线如下图所示逻辑描述非图表 首先在Java端我们会编写一个包含native方法声明的Java类并使用javac编译它然后用javahJDK 10之前或javac -hJDK 10及之后命令生成对应的C/C头文件.h。这个头文件定义了JNI需要实现的函数签名。 接着我们转向C/C端。根据生成的头文件我们编写具体的函数实现.c或.cpp文件。在这个实现中我们会调用第三方DLL提供的功能。然后使用Visual Studio Build Tools或MinGW的编译器cl.exe和链接器将我们的C/C代码与第三方DLL的导入库.lib链接最终生成我们自己的JNI DLL。 最后回到Java端。我们将编译好的JNI DLL、以及它所依赖的第三方DLL一起放置到Java库路径如项目根目录、java.library.path指定目录或系统PATH下。在IDEA中配置运行参数确保Java虚拟机JVM能正确加载它们。最终运行Java程序通过JNI接口调用我们DLL中的函数并间接使用第三方DLL的能力。注意一个关键的思维转变是你的Java程序不再直接面对第三方DLL而是面对一个你亲手打造的、集成了第三方功能的“代理”DLL。这层封装提供了更好的可控性和接口简化。3. 实战第一步从Java端定义Native接口让我们从熟悉的Java世界开始定义我们希望本地代码做什么。3.1 创建Java项目与Native方法声明在IntelliJ IDEA中创建一个新的Java项目例如命名为JniWithDepDemo。然后我们创建一个简单的Java类例如com.example.jni.NativeCalculator。package com.example.jni; public class NativeCalculator { // 声明一个native方法该方法将在我们的DLL中实现 // 假设这个方法的功能是利用第三方数学库计算两个数的平方和 public native double calculateSquareSum(double a, double b); // 另一个示例调用一个依赖第三方加密库的字符串处理函数 public native String processWithCrypto(String input); // 静态代码块用于在类加载时加载我们的JNI DLL static { // 这里加载的是我们即将创建的DLL的名字不含“.dll”后缀 // 在Windows上System.loadLibrary会尝试在java.library.path中查找“JniNativeWrapper.dll” System.loadLibrary(JniNativeWrapper); } // 一个简单的main方法用于测试 public static void main(String[] args) { NativeCalculator calc new NativeCalculator(); double result calc.calculateSquareSum(3.0, 4.0); // 3^2 4^2 25 System.out.println(Square Sum: result); String processed calc.processWithCrypto(HelloJNI); System.out.println(Processed String: processed); } }关键点解析native关键字这是方法的修饰符表明该方法的具体实现由本地代码提供。System.loadLibrary(“JniNativeWrapper”)这行代码至关重要。它告诉JVM去加载名为JniNativeWrapper.dll的动态库。库名必须与后续生成的DLL文件名主体部分一致Windows会自动添加.dll扩展名。这条语句通常放在静态块中确保类一被使用依赖的本地库就准备好。库的搜索路径System.loadLibrary会在java.library.path系统属性指定的路径中查找DLL。我们也可以在运行时使用System.setProperty(“java.library.path”, “新路径”)来修改但更常见的做法是使用System.load(“DLL的绝对路径”)来直接加载。在IDEA中我们可以通过运行配置轻松指定。3.2 生成JNI C/C头文件头文件是Java和C/C之间的契约。我们需要使用JDK工具从Java类生成它。打开终端Terminal或IDEA的内置终端导航到项目的源代码根目录即src目录所在的层级。编译Java类javac -d ./out ./src/com/example/jni/NativeCalculator.java。这会将编译后的.class文件输出到./out目录。生成C/C头文件。根据你的JDK版本有两种方式JDK 10及以上推荐使用javac的-h选项直接指定头文件输出目录。javac -h ./native -d ./out ./src/com/example/jni/NativeCalculator.java这条命令会编译Java文件并在当前目录下新建一个native文件夹在里面生成com_example_jni_NativeCalculator.h头文件。JDK 10以下先使用javah工具需确保在PATH中。javah -d ./native -cp ./out com.example.jni.NativeCalculator执行成功后你会在./native目录下找到生成的头文件。用编辑器打开它你会看到类似下面的内容/* DO NOT EDIT THIS FILE - it is machine generated */ #include jni.h /* Header for class com_example_jni_NativeCalculator */ #ifndef _Included_com_example_jni_NativeCalculator #define _Included_com_example_jni_NativeCalculator #ifdef __cplusplus extern C { #endif /* * Class: com_example_jni_NativeCalculator * Method: calculateSquareSum * Signature: (DD)D */ JNIEXPORT jdouble JNICALL Java_com_example_jni_NativeCalculator_calculateSquareSum (JNIEnv *, jobject, jdouble, jdouble); /* * Class: com_example_jni_NativeCalculator * Method: processWithCrypto * Signature: (Ljava/lang/String;)Ljava/lang/String; */ JNIEXPORT jstring JNICALL Java_com_example_jni_NativeCalculator_processWithCrypto (JNIEnv *, jobject, jstring); #ifdef __cplusplus } #endif #endif解读与注意事项#include jni.h这是JNI开发的核心头文件定义了JNIEnv、jobject、jdouble、jstring等所有JNI类型和函数。编译我们的C/C代码时必须能找到它它通常位于%JAVA_HOME%/include和%JAVA_HOME%/include/win32Windows目录下。函数名Java_{包名全路径点替换为下划线}_{类名}_{方法名}。这是一个严格的命名规范JVM就是通过这个冗长的名字来找到对应实现的。绝对不能写错。参数每个JNI函数至少有两个固定参数JNIEnv* env指向JNI函数表的指针所有与Java交互的调用都通过它和jobject obj调用该native方法的Java对象实例相当于Java中的this。后面才是你在Java中声明的参数被转换为JNI类型如jdouble,jstring。JNIEXPORT和JNICALL这是编译器相关的宏确保函数以正确的方式导出和调用我们照写即可。4. 核心环节创建依赖第三方DLL的JNI DLL这是整个项目的核心我们将编写C/C代码来实现头文件中声明的函数并在此过程中调用第三方DLL。4.1 准备第三方DLL及头文件为了模拟真实场景我们假设有一个名为ThirdPartyMath.dll的第三方库它提供了一个简单的函数double third_party_power(double base, double exponent);用于计算幂运算。同时我们还需要它的头文件third_party_math.h和导入库文件ThirdPartyMath.lib对于MSVC编译器或.a文件对于MinGW。实操心得在真实项目中第三方库通常会提供include文件夹含.h文件和lib文件夹含.lib或.a文件。.dll是运行时需要的而.lib/.a是编译链接时需要的。请确保你拥有这三样东西。假设我们将这些文件放在项目目录下的third_party文件夹中your_project/ ├── third_party/ │ ├── ThirdPartyMath.dll │ ├── ThirdPartyMath.lib (MSVC使用) │ └── third_party_math.h ├── native/ │ └── com_example_jni_NativeCalculator.h └── src/third_party_math.h内容可能很简单#pragma once #ifdef THIRDPARTYMATH_EXPORTS #define THIRDPARTYMATH_API __declspec(dllexport) #else #define THIRDPARTYMATH_API __declspec(dllimport) #endif THIRDPARTYMATH_API double third_party_power(double base, double exponent);4.2 编写JNI实现源文件在native目录下我们创建对应的C源文件JniNativeWrapper.cpp使用.cpp以支持C特性。// JniNativeWrapper.cpp #include jni.h // JNI核心头文件 #include “com_example_jni_NativeCalculator.h” // 生成的头文件 #include “../../third_party/third_party_math.h” // 第三方库头文件 #include cmath // 标准库例如使用sqrt #include string #include iostream // 实现第一个native方法计算平方和 (a^2 b^2) // 我们将使用第三方库计算平方用标准库计算和 JNIEXPORT jdouble JNICALL Java_com_example_jni_NativeCalculator_calculateSquareSum (JNIEnv *env, jobject obj, jdouble a, jdouble b) { // 调用第三方DLL的函数计算a的平方和b的平方 double a_square third_party_power(a, 2.0); double b_square third_party_power(b, 2.0); // 返回和 return (jdouble)(a_square b_square); } // 实现第二个native方法模拟一个使用第三方加密库的字符串处理这里简单反转并打印 // 假设第三方加密库有个函数void third_party_log(const char* message); // 为了演示我们假设这个函数在third_party_math.h中也有声明。 JNIEXPORT jstring JNICALL Java_com_example_jni_NativeCalculator_processWithCrypto (JNIEnv *env, jobject obj, jstring jInput) { // 1. 将Java的jstring转换为C风格的字符串UTF-8 const char* inputStr env-GetStringUTFChars(jInput, nullptr); if (inputStr nullptr) { return nullptr; // 内存溢出 } // 2. 模拟“处理”这里我们只是简单反转字符串并记录到日志假设的第三方函数 std::string cppStr(inputStr); std::string reversedStr(cppStr.rbegin(), cppStr.rend()); // 假设调用第三方库的日志函数此处仅为示意实际函数名和参数需根据真实库调整 // third_party_log((Processing string: cppStr).c_str()); std::cout [JNI] Processed string (simulated crypto log): cppStr - reversedStr std::endl; // 3. 释放从Java获取的字符串资源非常重要 env-ReleaseStringUTFChars(jInput, inputStr); // 4. 将处理后的C字符串转换回Java的jstring并返回 return env-NewStringUTF(reversedStr.c_str()); }关键点与避坑指南头文件路径#include “../../third_party/third_party_math.h”使用了相对路径。在实际编译时我们需要通过编译器的-Iinclude选项来指定这个目录这样代码中就可以用#include “third_party_math.h”了。JNI字符串处理这是JNI编程中最容易出错的地方之一。GetStringUTFChars用于获取指向Java字符串UTF-8编码的指针使用完毕后必须调用对应的ReleaseStringUTFChars释放否则会导致内存泄漏。同样NewStringUTF用于从C字符串创建新的Java字符串对象。异常处理JNI函数调用可能会抛出Java异常例如如果GetStringUTFChars因内存不足失败。健壮的JNI代码应该在关键调用后检查异常使用env-ExceptionCheck()或env-ExceptionOccurred()并及时处理或清除。第三方函数调用我们直接像调用普通C函数一样调用了third_party_power。编译器在编译时需要通过头文件知道它的存在链接器在链接时需要.lib文件来解析这个函数在DLL中的位置。4.3 使用Visual Studio Build Tools编译与链接这是将C代码变成DLL的关键步骤。我们将使用命令行工具这能让你更清晰地理解整个过程。打开开发者命令提示符在Windows开始菜单中找到“Visual Studio 2022”或“Visual Studio 2019”文件夹选择“x64 Native Tools Command Prompt”根据你的Java是64位选择x64如果是32位则选择x86。这将打开一个配置好VC编译环境cl.exe,link.exe等的命令行窗口。导航到项目目录使用cd命令切换到你的项目根目录。执行编译链接命令这是一条较长的命令我们拆解来看cl /EHsc /LD /Fe:JniNativeWrapper.dll /I%JAVA_HOME%\include /I%JAVA_HOME%\include\win32 /I.\third_party JniNativeWrapper.cpp com_example_jni_NativeCalculator.cpp /link /LIBPATH:.\third_party ThirdPartyMath.libcl: Visual C编译器。/EHsc: 指定C异常处理模型。/LD: 告诉编译器我们要生成一个DLL而不是EXE。/Fe:JniNativeWrapper.dll: 指定输出的DLL文件名。/I“路径”: 添加头文件包含目录。这里添加了JNI头文件路径和第三方头文件路径。%JAVA_HOME%需要指向你的JDK安装目录。JniNativeWrapper.cpp …: 要编译的源文件列表。注意我们还需要编译生成的头文件对应的“桩”文件不实际上com_example_jni_NativeCalculator.h只是头文件实现都在JniNativeWrapper.cpp里了。如果头文件声明了函数但实现分散在多个.cpp文件需要都列上。/link: 后面的选项传递给链接器。/LIBPATH:“.\third_party”: 告诉链接器在哪个目录下寻找.lib文件。ThirdPartyMath.lib: 指定要链接的第三方库的导入库。这是关键它告诉链接器我们的DLL将依赖ThirdPartyMath.dll中的函数。执行这条命令后如果一切顺利你会在当前目录下看到生成的JniNativeWrapper.dll以及伴随的JniNativeWrapper.lib导入库和JniNativeWrapper.exp导出文件等。重要提示如果第三方DLL是使用MinGWGCC编译的它可能提供的是.a文件静态库或导入库。在这种情况下你不能直接使用MSVC的link.exe来链接.a文件。通常的解决方案是要么全部统一使用MinGW工具链用g编译要么向第三方库提供者索取MSVC编译版本的.lib和.dll。混合编译器工具链是DLL地狱的主要源头之一。5. 在IDEA中配置与运行JNI项目DLL生成后我们需要让Java程序在IDEA中能顺利找到并加载它。5.1 组织运行时文件将编译生成的文件和依赖库整理到一个方便管理的地方。建议在项目根目录创建libs或bin文件夹。your_project/ ├── libs/ │ ├── JniNativeWrapper.dll (我们编译的JNI DLL) │ └── ThirdPartyMath.dll (它依赖的第三方DLL) ├── out/ (Java类文件) ├── src/ └── ...黄金法则JniNativeWrapper.dll和ThirdPartyMath.dll必须放在同一个目录或者都在Java的库搜索路径下。因为当系统加载JniNativeWrapper.dll时它会立即尝试加载其依赖的ThirdPartyMath.dll。如果找不到加载就会失败。5.2 配置IntelliJ IDEA运行参数打开运行/调试配置在IDEA右上角点击运行配置下拉菜单选择“Edit Configurations...”。添加VM选项在对应的Application配置你的NativeCalculator主类中找到“VM options”输入框。设置库路径添加以下VM参数-Djava.library.path./libs这告诉JVM除了默认路径还要去项目根目录下的libs文件夹里寻找本地库DLL。你也可以使用绝对路径。设置工作目录Working directory确保“Working directory”指向你的项目根目录。这有助于使用相对路径./libs。5.3 运行与调试运行现在直接运行NativeCalculator的main方法。如果一切配置正确你将看到控制台输出Square Sum: 25.0 [JNI] Processed string (simulated crypto log): HelloJNI - INJolleH Processed String: INJolleH恭喜你成功通过JNI调用了自己的DLL并且该DLL也成功调用了第三方DLL的功能。调试JNI代码进阶首先你需要用调试模式编译你的C DLL。在之前的cl命令中添加调试符号生成选项/Zi并确保优化关闭/Od。cl /Zi /Od /EHsc /LD /Fe:JniNativeWrapper.dll /I... (其余参数不变) ...在IDEA中以调试模式启动Java程序。打开Visual Studio或其他C调试器如VS Code配合C插件使用“附加到进程”功能找到正在运行的java.exe进程并附加。在你的JniNativeWrapper.cpp源文件中设置断点。当Java代码调用到native方法时调试器就会在C断点处停下。这是一个相对高级的操作需要同时配置Java和C两边的调试环境。对于初步排查问题更常用的方法是使用printf或std::cout在C代码中输出日志。6. 深度依赖管理与疑难问题排查实录“该DLL同时依赖第三方DLL”是标题中的难点也是实践中错误的高发区。下面我们系统性地梳理相关问题与解决方案。6.1 依赖加载失败UnsatisfiedLinkError的多种面孔当你遇到UnsatisfiedLinkError时不要慌张根据错误信息细分问题找不到主JNI DLLException in thread main java.lang.UnsatisfiedLinkError: no JniNativeWrapper in java.library.path原因System.loadLibrary(“JniNativeWrapper”)无法在java.library.path指定的任何目录中找到JniNativeWrapper.dll。排查检查-Djava.library.path的VM参数是否设置正确路径是否包含DLL所在目录。尝试使用System.load(“D:\full\path\to\JniNativeWrapper.dll”)绝对路径加载以确认是否是路径问题。检查DLL文件名是否正确大小写不敏感但最好一致是否真的存在于指定目录。找到主DLL但加载失败Exception in thread main java.lang.UnsatisfiedLinkError: D:\path\to\JniNativeWrapper.dll: Cant find dependent libraries或者更具体的Exception in thread main java.lang.UnsatisfiedLinkError: D:\path\to\JniNativeWrapper.dll: The specified module could not be found.原因操作系统加载器找到了JniNativeWrapper.dll但在加载它时发现它依赖的某个DLL如ThirdPartyMath.dll或它依赖的C运行时库msvcr140.dll、vcruntime140.dll等找不到。排查这是最常见的问题。使用Dependency Walker打开JniNativeWrapper.dll它会以树形图展示所有依赖的DLL。红色标记的DLL就是找不到的。重点关注第三方DLL如ThirdPartyMath.dll。Windows系统DLL通常没问题。VC Redistributable运行时库如MSVCP140.dll,VCRUNTIME140_1.dll。你的编译环境如VS2019需要对应的运行时库。解决方案是确保目标机器安装了对应版本的 Visual C Redistributable 或者将/MT静态链接运行时库编译选项传递给cl编译器但这会增大DLL体积。检查依赖DLL位置确保所有依赖的DLL特别是第三方DLL都位于以下任一目录与JniNativeWrapper.dll同一目录。首选方案系统PATH环境变量包含的目录。Windows系统目录如C:\Windows\System32不推荐放这里。JNI函数名解析失败Exception in thread main java.lang.UnsatisfiedLinkError: com.example.jni.NativeCalculator.calculateSquareSum(DD)D原因DLL加载成功了但JVM在DLL中找不到与Java native方法签名完全匹配的函数。函数名、参数类型或返回类型对不上。排查使用dumpbin /exports JniNativeWrapper.dll命令查看DLL实际导出了哪些函数名。与com_example_jni_NativeCalculator.h中声明的函数名仔细比对。特别注意C和C编译导致的名称修饰Name Mangling。我们的实现文件是.cpp且头文件用extern “C”包裹就是为了避免C的名称修饰。如果实现文件是.cC语言则没有这个问题。确保你编译链接的是最终包含函数实现的.obj/.cpp文件。6.2 编译链接期常见错误无法打开包含文件“jni.h”解决检查/I选项指定的%JAVA_HOME%\include和%JAVA_HOME%\include\win32路径是否正确。JAVA_HOME环境变量是否指向有效的JDK目录。无法解析的外部符号third_party_power解决这发生在链接阶段。检查/LIBPATH是否正确指向了包含ThirdPartyMath.lib的目录。链接器参数中是否明确列出了ThirdPartyMath.lib。.lib文件版本是否与编译器兼容MSVC版本匹配。6.3 运行时逻辑错误与调试技巧JNI本地引用内存泄漏 如前所述GetStringUTFChars、GetTypeArrayElements等函数获取的资源必须释放ReleaseStringUTFChars,ReleaseTypeArrayElements。长期运行的本地方法如回调中创建的大量本地引用NewObject,NewString等如果未及时用DeleteLocalRef删除可能会耗尽JNI本地引用表的容量。对于不会返回给Java的本地引用养成及时删除的习惯。在JNI代码中处理Java异常 Java代码可能在调用JNI方法后抛出异常而本地代码继续执行。或者本地代码调用JNI函数如CallObjectMethod可能引发新的异常。好的实践是在关键JNI调用后检查异常jstring jstr env-NewStringUTF(“test”); if (env-ExceptionCheck()) { env-ExceptionDescribe(); // 打印异常信息到stderr env-ExceptionClear(); // 清除异常避免影响后续操作 // 进行错误处理或返回 return nullptr; }跨线程调用JNIEnvJNIEnv*指针是线程相关的。绝对不能将一个线程获取的JNIEnv传递给另一个线程使用。如果需要在本地创建的新线程中回调Java必须使用JavaVM全局单例的AttachCurrentThread函数来获取属于当前线程的JNIEnv。6.4 64位/32位x64/x86匹配问题这是一个极其隐蔽的坑。你的JavaJVM必须是64位的那么你编译的DLL也必须是64位的使用x64 Native Tools Command Prompt。如果Java是32位的DLL也必须是32位的。混合架构会导致UnsatisfiedLinkError。使用java -version查看Java版本确保与你的编译目标一致。7. 项目优化与进阶实践掌握了基础流程后可以考虑以下优化来提升项目的健壮性和可维护性。7.1 使用CMake或Visual Studio项目管理C代码对于复杂的JNI本地代码使用命令行编译会变得繁琐。可以创建CMakeLists.txt或直接的Visual Studio项目来管理。CMake示例cmake_minimum_required(VERSION 3.10) project(JniNativeWrapper) # 查找Java获取JNI头文件路径 find_package(Java REQUIRED) find_package(JNI REQUIRED) include_directories(${JNI_INCLUDE_DIRS}) # 包含第三方头文件 include_directories(${PROJECT_SOURCE_DIR}/third_party) # 添加源文件创建共享库 add_library(JniNativeWrapper SHARED JniNativeWrapper.cpp) # 链接第三方库 target_link_libraries(JniNativeWrapper ${PROJECT_SOURCE_DIR}/third_party/ThirdPartyMath.lib) # 设置输出目录方便Java项目引用 set_target_properties(JniNativeWrapper PROPERTIES LIBRARY_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/libs)然后使用CMake生成VS工程或Makefile实现跨平台编译管理。7.2 封装JNI调用提供更友好的Java API直接在Java中调用native方法往往比较原始。一个好的实践是创建一个Java工具类将复杂的JNI交互如对象转换、错误处理封装起来对外提供更安全、更符合Java习惯的API。public class JniWrapper { static { System.loadLibrary(“JniNativeWrapper”); } private static native double nativeCalculateSquareSum(double a, double b); private static native String nativeProcessWithCrypto(String input); // 对外的友好API可以进行参数校验、异常转换等 public static double calculateSquareSum(double a, double b) { if (Double.isNaN(a) || Double.isNaN(b)) { throw new IllegalArgumentException(“Input must be valid numbers”); } try { return nativeCalculateSquareSum(a, b); } catch (Throwable t) { throw new RuntimeException(“JNI operation failed”, t); } } // ... 其他方法 }7.3 处理复杂的第三方依赖链如果你的第三方DLLA.dll又依赖另一个DLLB.dll甚至B.dll还依赖C.dll你需要确保整个依赖链上的所有DLL在运行时都可用。使用Dependency Walker分析A.dll把缺失的B.dll、C.dll都找到并和你的JniNativeWrapper.dll放在一起。有时这些依赖可能是Windows系统自带的库如KERNEL32.dll,USER32.dll则无需担心。7.4 考虑跨平台Linux/macOSJNI本身是跨平台的。要实现跨平台你需要将Windows的DLL概念对应到Linux的共享对象.so和macOS的动态库.dylib。在Java中使用System.loadLibrary(“JniNativeWrapper”)它会根据操作系统自动加载JniNativeWrapper.dllWindows、libJniNativeWrapper.soLinux或libJniNativeWrapper.dylibmacOS。为每个平台准备对应的编译脚本CMake可以很好地管理这一点分别编译生成对应的本地库文件。在打包分发时将不同平台的本地库放在不同的目录如lib/win32-x86-64,lib/linux-x86-64,lib/darwin-aarch64然后在程序启动时根据当前操作系统和架构动态选择加载路径。
