| ylbtech-Java-类库：JNI |
JNI是Java Native Interface的缩写，它提供了若干的API实现了Java和其他语言的通信（主要是C&C++）。从Java1.1开始，JNI标准成为java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI一开始是为了本地已编译语言，尤其是C和C++而设计的，但是它并不妨碍你使用其他编程语言，只要调用约定受支持就可以了。使用java与本地已编译的代码交互，通常会丧失平台可移植性。但是，有些情况下这样做是可以接受的，甚至是必须的。例如，使用一些旧的库，与硬件、操作系统进行交互，或者为了提高程序的性能。JNI标准至少要保证本地代码能工作在任何Java 虚拟机环境。
| 1.返回顶部 |
1、
JNI的角色
JNI可以这样与本地程序进行交互：
1、你可以使用JNI来实现“本地方法”（native methods），并在JAVA程序中调用它们。
2、JNI支持一个“调用接口”（invocation interface），它允许你把一个JVM嵌入到本地程序中。本地程序可以链接一个实现了JVM的本地库，然后使用“调用接口”执行JAVA语言编写的软件模块。例如，一个用C语言写的浏览器可以在一个嵌入式JVM上面执行从网上下载下来的applets。
JNI的副作用
一旦使用JNI，JAVA程序就丧失了JAVA平台的两个优点：
1、程序不再跨平台。要想跨平台，必须在不同的系统环境下重新编译本地语言部分。
2、程序不再是绝对安全的，本地代码的不当使用可能导致整个程序崩溃。一个通用规则是，你应该让本地方法集中在少数几个类当中。这样就降低了JAVA和C之间的耦合性。
应用场合
当你开始着手准备一个使用JNI的项目时，请确认是否还有替代方案。应用程序使用JNI会带来一些副作用。下面给出几个方案，可以避免使用JNI的时候，达到与本地代码进行交互的效果：
1、JAVA程序和本地程序使用TCP/IP或者IPC进行交互。
2、当用JAVA程序连接本地数据库时，使用JDBC提供的API。
3、JAVA程序可以使用分布式对象技术，如JAVA IDL API。
这些方案的共同点是，JAVA和C处于不同的线程，或者不同的机器上。这样，当本地程序崩溃时，不会影响到JAVA程序。
下面这些场合中，同一进程内JNI的使用无法避免：
1、程序当中用到了JAVA API不提供的特殊系统环境才会有的特征。而跨进程操作又不现实。
2、你可能想访问一些己有的本地库，但又不想付出跨进程调用时的代价，如效率，内存，数据传递方面。
3、JAVA程序当中的一部分代码对效率要求非常高，如算法计算，图形渲染等。
总之，只有当你必须在同一进程中调用本地代码时，再使用JNI。
JNI的演化
JDK1.0包含了一个本地方法接口，它允许JAVA程序调用C/C++写的程序，许多第三方的程序和JAVA类库。如：java.lang,java.io,java.net等都依赖于本地方法来访问底层系统环境的特征。
不幸的是，JDK1.0中的本地方法有两个主要问题：
1、本地方法像访问C中的结构（structures）一样访问对象中的字段。尽管如此，JVM规范并没有定义对象怎么样在内存中实现。如果一个给定的JVM实现在布局对象时，和本地方法假设的不一样，那你就不得不重新编写本地方法库。
2、因为本地方法可以保持对JVM中对象的直接指针，所以，JDK1.0中的本地方法采用了一种保守的GC策略。
JNI的诞生就是为了解决这两个问题，它可以被所有平台下的JVM支持：
（1）每一个JVM实现方案可以支持大量的本地代码。
（2）开发工具作者不必处理不同的本地方法接口。
（3）本地代码可以运行在不同的JVM上面。
JDK1.1中第一次支持JNI，但是，JDK1.1仍在使用老风格的本地代码来实现JAVA的API。这种情况在JDK1.2下被彻底改变成符合标准的写法。
设计的目的
标准的java类库可能不支持你的程序所需的特性。或许你已经有了一个用其他语言写成的库或程序，而你希望在java程序中使用它。
你可能需要用底层语言实现一个小型的时间敏感代码，比如汇编，然后在你的java程序中调用这些功能。
...
...
2、
| 2.返回顶部 |
| 3.返回顶部 |
| 4.返回顶部 |
| 5.返回顶部 |
1、
2、
| 6.返回顶部 |
 |
作者：ylbtech 出处：http://ylbtech.cnblogs.com/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 |