前言：
这次的项目经历让我尝了一次苦头，在最后一切顺利成功执行的时候，就决定要写下我人生的第一篇博客。
本次项目的动态库与正常动态库不同的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>
