手把手教你通过Eclipse工程配置调用JNI完全攻略

来源：互联网发布：淘宝中秋节活动策划编辑：程序博客网时间：2024/05/17 06:32

当你找到并鬼使神差地打开这个博文的时候，我敢肯定你已经知道什么是JNI，基本概念就不粘贴了。

百度出来的JNI调用方法，前三页几乎毫不例外的都是几年前的资料，告诉你如何设置一大堆莫名其妙的参数、如何通过命令行加工出dll并调用出来的，遗憾的是笔主打开的那堆帖子，多少都有些操作上的出入，再一个笔主对嘿嘿的命令行窗口无爱，并且，例外的帖子笔主还木有幸看到...

所以笔主狠心放下公司工作，抛弃领导的绩效奖金，花了大半天时间研究JNI的调用方法（尤其不用写命令那种），终于赶在下班的前三分钟，顺利完全通过eclipse界面调用出自定义的dll方法！那个激动就像中美建交或日本沉没或苍老师来我家做客那一瞬间那么振奋人心！！

简单准备工作：

以下具体操作方法可以直接百度，答案几乎是唯一可信的。

安装JDK，配置系统环境变量
准备好一个带CDT插件的Eclipse，笔主使用的是google的ADT Bundle，自带了CDT，对应Eclipse 3.8.0版
下载一个MinGW（免费的C/C++等语言编译器套件），笔主限于公司垃圾网络，测试时使用mingw-offline-install-20120426 v4.6.2版，安装时仅需勾选（在线安装版下载数据量约50Mb）：

C Compiler
C++ Compiler
MinGW Developer Toolkit (Indudes MSYS Basic System)

配置MinGW的环境变量：

打开环境变量(系统变量)，添加 MINGW_HOME 变量，变量值是刚才MinGW的安装地址，如 D:\Program Files\MinGW
设置path变量，编辑path变量添加 %MINGW_HOME%\bin;%MINGW_HOME%\msys\1.0\bin;
添加 LIBRARY_PATH 变量，变量值 %MINGW_HOME%\lib
添加 C_INCLUDE_PATH 变量，变量值 %JAVA_HOME%\include;%JAVA_HOME%\include\win32;%MINGW_HOME%\include
添加 CPLUS_INCLUDE_PATH 变量，内容 %JAVA_HOME%\include;%JAVA_HOME%\include\win32;%MINGW_HOME%\lib\gcc\mingw32\4.5.2\include\c++
Win7点击确定后立即生效，若未生效请重启系统（参考安装JDK时配置操作）

第4、5步额外添加的%JAVA_HOME%\include;%JAVA_HOME%\include\win32;是为了让eclipse在c/c++项目中自动引入这个目录下的各种头文件，例如 jni.h，也可在具体项目的属性中以下位置进行指定：

调用JNI全过程：

创建一个普通java工程 Test，添加一个专门负责引入调用本地库的类 Native，代码如下：

1 public class Native {2     // 声明自定义本地库方法接口3     native public static void run();4     5     // 自动加载本地库文件，如文件名全称为 myCLib.dll6     static{7         System.loadLibrary("myCLib");8     }9 }

打开CMD....好吧，笔主承认标题党了，整个博文仅此一处需要一句简单的命令！ CMD导航至项目文件夹下的 src 目录，输入 javah test.Native（需要使用包名.类名的完整限定名称），生成本地方法接口头文件 test_Native.h：

刷新eclipse的 Package Explorer 应该会变成这样的目录状态，其中刚才刚才生成的 test_Native.h 文件代码如下图示（笔主抢闸创建了Test类，稍候用于调用Native类的本地方法）：

创建一个新的 C 工程 MyC，期待编译成dll的时候，选择 Shared Library 下的模板：

在 MyC 工程内创建一个文件夹 src ，并将刚才 Test 项目中生成的 test_Native.h 头文件拷贝（或剪切）到 MyC 工程的 src 文件夹下，Test 工程下的 test_Native.h 文件在后面的项目运行过程中将不再起任何作用，可删：

* 打开 MyC 工程下的 test_Native.h ，若 #include <jni.h> 提示 Unresolved inclusion: <jni.h> 的错误警告（如下图所示），则表明目前这个C项目没有指定 jni.h 的头文件位置，参考上文配置MinGW的环境变量的第4、5步进行配置：

** MyC 工程文件中接口函数代码上提示的 Syntax error 可以暂时忽略，据闻是eclipse语法检测的一个bug：

在 MyC 工程 src 文件夹中，新建一个C的实现类 NativeC.c ，引入接口头文件 jni.h、test_Native.h ，并编写接口函数 JNICALL Java_test_Native_run 的实现（函数接口直接从 test_Native.h 中完整拷贝过来，注意加上形参）：

1 #include <jni.h>2 #include "test_Native.h"3 #include <stdio.h>4 5 JNIEXPORT void JNICALL Java_test_Native_run6   (JNIEnv *env, jclass clazz){7     puts("Hello JAVA, I am C.");8 }

此时工程看起来应该是这样子的：

由于使用 minGW 默认生成的 dll 函数签名带有 @ 分隔符，将导致后面JNI调用时产生 java.lang.UnsatisfiedLinkError: xoxoclass.xoxomethod() 错误，因此需要执行以下步骤消除多余的 @ 符号。

配置 MyC 工程： MyC 工程上右键菜单 Properties ，左侧选择 C/C++ Build -> Settings ，右侧 Configuration 中显示的为当前正在显示的编译模板，[ Active ] 表示通过 Project->Build Project 菜单编译时使用的默认编译版本， minGW 将根据这些模板的属性设置，编译生成多套版本的 dll 或 exe ，有洁癖的同学可通过最右侧的 Manage Configurations... 按钮增删编译模板：

为了对比效果，笔主决定增加一套新模板 ReleaseNoAt ，继承默认的 Release 模板属性参数，并设置为Active，决不是因为洁癖或什么奇怪的原因：

OK返回刚才的编译模板属性配置界面，在 ReleaseNoAt 模板下，Tool Settins 页中的 MinGW C Linker -> Miscellaneous ，Linker flags 框中输入 -Wl,--kill-at，点击最下方的 Apply：

点击 MinGW C Linker ，显示的参数结果应该是这样的：

如果之前建立的C工程不是使用 Shared Library 模板，并且默认编译出的不是 dll 文件，可以在此选择 Build Artifact 页进行修改配置，Artifact Type 中选择 Shared Library ，Artifact extension 中选择 dll 即可，Output prefix 可指定输出 dll 文件的命名前缀：

OK确定返回代码编辑界面，在 MyC 工程上右键菜单，Build Configurations->Build All，生成所有模板的dll文件版本：

各版本 dll 如下图所示，控制台中可以见到每个 dll 生成所用的命令参数（现在显示的是 ReleaseNoAt 版本，即唯一配置了去掉@符号的模板）：

为了验证默认 Release 与 ReleaseNoAt 版本的区别，可用 dllexp 这个工具打开这两个 dll 文件进行查看（具体方法不告诉你）：

Release版（下面这个 @8 就是一切麻烦的罪魁祸首）

ReleaseNoAt版（干净了）

回到eclipse，在 Test 工程中新建文件夹 dll （命名随意），并将上面生成的 ReleaseNoAt版 libMyC.dll 拷贝到这个dll文件夹中，重命名为 myCLib.dll（因为上文 Native类中通过 System.loadLibrary("myCLib"); 加载了这个名字的dll文件，当然你也可以修改代码变成 System.loadLibrary("libMyC"); 来取代重命名），此后 MyC 工程将不再起任何作用，可删：

配置 Test工程属性，指定工程的本地库目录，直接看图：

Test工程 test包中新建 Test类（由于时间关系，笔主已经事先偷偷违建了），在main方法中引用 Native类的本地方法run()：

1 public class Test {2 3     public static void main(String[] args) {4         Native.run();5     }6 }

最后一步，运行起来...好吧，上面已经偷跑了，最终结果如上图所示，Hello, I am Wavky.

0 0