JNI完全手册.doc

1-简介本章介绍Java本地接口(JavaNativeInterface,JNI)。JNI是本地编程接口。它使得在Java虚拟机(VM)内部运行的Java代码能够与用其它编程语言(如C、C++和汇编语言)编写的应用程序和库进行互操作。JNI最重要的好处是它没有对底层Java虚拟机的实现施加任何限制。因此,Java虚拟机厂商可以在不影响虚拟机其它部分的情况下添加对JNI的支持。程序员只需编写一种版本的本地应用程序或库,就能够与所有支持JNI的Java虚拟机协同工作。本章论及以下主题:,但是有时单独用Java不能满足应用程序的需要。程序员使用JNI来编写Java本地方法,可以处理那些不能完全用Java编写应用程序的情况。以下示例说明了何时需要使用Java本地方法:标准Java类库不支持与平台相关的应用程序所需的功能。已经拥有了一个用另一种语言编写的库,而又希望通过JNI使Java代码能够访问该库。想用低级语言(如汇编语言)实现一小段时限代码。通过用JNI编程,可以将本地方法用于:创建、检查及更新Java对象(包括数组和字符串)。调用Java方法。捕捉和抛出异常。加载类和获得类信息。执行运行时类型检查。也可以与调用API一起使用JNI,以允许任意本地应用程序嵌入到Java虚拟机中。这样使得程序员能够轻易地让已有应用程序支持Java,而不必与虚拟机源代码相链接。背景目前,不同厂商的虚拟机提供了不同的本地方法接口。这些不同的接口使程序员不得不在给定平台上编写、维护和分发多种版本的本地方法库。下面简要分析一下部分已有本地方法接口,例如:。遗憾的是,有两点原因使得该接口不适合于其它Java虚拟机。第一,平台相关代码将Java对象中的域作为C结构的成员来进行访问。但是,Java语言规范没有规定在内存中对象是如何布局的。如果Java虚拟机在内存中布局对象的方式有所不同,程序员就不得不重新编译本地方法库。第二,。例如,无限制地使用unhand宏使得有必要以保守方式扫描本地堆栈。scape建议使用Java运行时接口(JRI),它是Java虚拟机所提供服务的通用接口。JRI的设计融入了可移植性---它几乎没有对底层Java虚拟机的实现细节作任何假设。JRI提出了各种各样的问题,包括本地方法、调试、反射、嵌入(调用)等等。接口MicrosoftJava虚拟机支持两种本地方法接口。在低一级,它提供了高效的原始本地接口(RNI)。RNI提供了与JDK本地方法接口有高度源代码级的向后兼容性,尽管它们之间还有一个主要区别,即平台相关代码必须用RNI函数来与垃圾收集器进行显式的交互,而不是依赖于保守的垃圾收集。在高一级,接口为Java虚拟机提供了与语言无关的标准二进制接口。对象。类显示给系统的其余部分。目标我们认为统一的,经过细致考虑的标准接口能够向每个用户提供以下好处:每个虚拟机厂商都可以支持更多的平台相关代码。工具构造器不必维护不同的本地方法接口。应用程序设计人员可以只编写一种版本的平台相关代码就能够在不同的虚拟机上运行。获得标准本地方法接口的最佳途径是联合所有对Java虚拟机有兴趣的当事方。因此,我们在Java获得许可方之间组织了一系列研讨会,对设计统一的本地方法接口进行了讨论。从研讨会可以明确地看出标准本地方法接口必须满足以下要求:二进制兼容性-主要的目标是在给定平台上的所有Java虚拟机实现之间实现本地方法库的二进制兼容性。对于给定平台,程序员只需要维护一种版本的本地方法库。效率-若要支持时限代码,本地方法接口必须增加一点系统开销。所有已知的用于确保虚拟机无关性(因而具有二进制兼容性)的技术都会占用一定的系统开销。我们必须在效率与虚拟机无关性之间进行某种折衷。功能-接口必须显示足够的Java虚拟机内部情况以使本地方法能够完成有用的任务。Java本地接口方法我们希望采用一种已有的方法作为标准接口,因为这样程序员(程序员不得不学习在不同虚拟机中的多种接口)的工作负担最轻。遗憾的是,scape的JRI最接近于我们所设想的可移植本地方法接口,因而我们采用它作为设计起点。熟悉JRI的读者将会注意到在API命名规则、方法和域ID的使用、局部和全局引用的使用,等等中的相似点。虽然我们进行了最大的努力,但是JNI并不具有对JRI的二进制兼容性,不过虚拟机既可以支持JRI,又可以支持JNI。,因为它可以解决使用非保守的垃圾收集器的本地方法的问题。然而,RNI不适合用作与虚