JAVA调用C/C++动态库 开发笔记
前言:
这次的项目经历让我尝了一次苦头,在最后一切顺利成功执行的时候,就决定要写下我人生的第一篇博客。
本次项目的动态库与正常动态库不同的2个情况是:一是动态库dll内部需要调用一个与dll在同级目录下的一个配置文件;二是动态库在运行过程中会向动态库dll同级目录下创建并写入一个日志文件(我这边说的同级目录可能不太准确,具体后文会提到)。
</br>
一、调用方式:
JAVA调用C/C++动态库有很多方法,常用的有JNI(Java Native Interface)、JNA(Java Native Access)。
- JNI:早在JAVA1.1版本就开始支持,它定义了一种公用的语法,当java和c/c++双方都遵循该语法时,可以互相调用。所以使用JNI不能直接调用一般的C/C++库,而必须借助于一个中间动态库,该中间动态库实现了JAVA-JNI语法-C/C++的转换(或者你所调用的动态库原生就封装了JNI)。如果对C++稍微懂一点,其实使用起来也不难。
- JNA:在C#中,使用[DLLImport]可以非常方便的调用原生的C/C++动态库,所以sun公司开发了JNA来使JAVA可以像C#一样方便的调用动态库。不过在使用过程中感觉内部原理还是使用了JNI的语法库。不过至少对于我们不懂C++的来说,可以直接调用原生的动态库,而不需要再去生成一个C++的中间动态库了。
所以这次在尝试了JNI之后还是选择了JNA。
</br>
二、关于x32和x64:
如果C/C++动态库使用x32,那必须运行在x32的Tomcat上,并且使用x32的JRE。所以如果不幸拿到股东动态库,未提供x64版本,那只能单独部署x32服务器提供对应的接口,而x64主站点通过http方式调用该接口程序来访问动态库。
如果在x64Tomcat上加载x32版本动态库,将得到如下错误信息:
"Can't load IA 32-bit .dll on a AMD 64-bit platform"
调用方法及DLL存放位置:
先来简单的看一下JNI和JNA两种方式加载动态库的代码:
JNI:
public class ImportDllTest {
//加载动态库
static{
//通过决定地址加载动态库
//System.load("d:\\C2JavaTest.dll");
//通过库名加载动态库,不加.dll后缀,自适应.dll和liunx平台的.so
System.loadLibrary("C2JavaTest");
}
//定义动态库接口方法
public native String subString(String str, int startIndex, int length);
public static void main(String[] args){
ImportDllTest importDll = new ImportDllTest();
String str = importDll.subString("test",1,2);
}
}
JNA:
引用JNA包
<dependency>
<groupId>com.sun.jna</groupId>
<artifactId>jna</artifactId>
<version>3.0.9</version>
</dependency>
定义接口类,继承com.sun.jna.Library
//必须继承com.sun.jna.Library
public interface ImportDllTest extends Library {
//加载动态库,使用动态库名称加载,不带.dll后缀,会自动识别liunx环境下的.so库。也可以使用决定地址加载动态库
public static ImportDllTest Instance = (ImportDllTest) Native.loadLibrary("C2JavaTest", ImportDllTest.class);
//定义动态库接口方法
String subString(String str, int startIndex, int length);
public class Main{
public static void main(String[] args){
String str = ImportDllTest.Instance.subString("test",1,2);
}
}
}
关于是否加载到动态库:
两种加载动态库都可以使用动态库名称或者绝对路径来加载,在调试过程中,JNA如果没找到动态库并不会给出明确的提示,而JNI的加载方法会明确抛出找不到动态库的异常,所以即使是使用JNA方式,但在一开始不确定是否将动态库放在了正确位置,是否成功的加载了动态库的时候可以借助于JNI的Systetm.loadLibrary来协助判断是否成功的加载了对应的动态库。
</br>
三、动态库位置:
加载动态库都可以使用决定地址来加载。但本次项目加载的动态库会需要调用同级目录下的配置文件,使用绝对地址的方式我是没能成功的加载到配置文件(因为也不清楚动态库里实际加载配置文件的具体实现)。使用动态库名称加载,那动态库到底应该放在哪里,网上查了很多资料,有放system32的,有放jdk/jre的,有放tomcat里的,有放环境变量配置里的。在追求尽量不给后续运维造成太大困扰(放系统system32,或jdk/jre,部署时很容易忘记或错乱),尽可能找最优的方案。
最后我借助于动态库生成的日志文件,来判断默认加载动态库的路径:
应用程序:
Main方法测试时,动态库及配置文件需要放到运行时选择的工作目录下。
动态库和配置文件要放在:
同时生成的日志文件也将会在该目录下
Tomcat部署程序
Tomcat部署时,尝试过很多方式,但是最后选择了Tomcat的bin目录
cd Tomcat/bin
</br>
四、JAVA与C/C++参数对应
java的char是2字节,byte是1字节;c/c++的char是1字节;
作为JAVA传入C/C++参数:
JAVA | C/C++ |
---|---|
byte[] | char[]/char* |
String | char[]/char* |
int | int |
作为JAVA中传入,C/C++里out的参数:
C/C++ | JAVA |
---|---|
char[]/char* | byte[] |
调用是要先将定义的byte数组空间定义好,c++中才可以在已经定义的空间中写值。
//out参数长度8字节内容
byte[] out_param = new byte[8];
</br>
五、总结
- 可以借助于JIN确定动态库是否能正确加载到。如果动态库不需要配置文件,完全可以使用决定路径来进行加载。
- 明确动态库的版本,是x32还是x64。不同版本要使用对应的tomcat和jre。
- 确定传递参数类型,java中一定要记得不可以使用char来和c++的char交互,一定是要byte或String(为什么String可以,猜测可能JIN或JNA在内部转换成了byte)。
- 最后如果动态库能有人员配合一起调试,那是一个美好的事情。
</br>
</br>
这次把成功的几个关键点调用整理在此。本次项目也是因为调用的古董动态库,没有文档,没有错误说明,所有返回都靠猜测,所以不确实是java调用问题还是本身业务问题。前前后后折腾好几周,最后总算还是有了一个好的结果。
以上有任何不对的地方,敬请指正。
</br>
</br>