《Java编程思想第4版[中文版](PDF格式)》第281章

令里不规定想调用哪个版本，JVM　就会试着自行判断。但这一操作会在程序执行时花费较长的时间。所以，　
我们一般可用ansi，unicode　或　auto　修改符硬性规定。
欲了解这些特性更详细的情况，请参考微软公司提供的技术文档。
A。4　本原接口（RNI　）
同J/Direct　相比，RNI　是一种比非　Java　代码复杂得多的接口；但它的功能也十分强大。RNI　比J/Direct　更　
接近于　JVM，这也使我们能写出更有效的代码，能处理固有方法中的　Java　对象，而且能实现与JVM　内部运行　
机制更紧密的集成。
RNI　在概念上类似Sun　公司的JNI。考虑到这个原因，而且由于该产品尚未正式完工，所以我只在这里指出它　
们之间的主要差异。欲了解更详细的情况，请参考微软公司的文档。
JNI　和　RNI　之间存在几方面引人注目的差异。下面列出的是由msjavah　生成的　C　头文件（微软提供的msjavah　
在功能上相当于Sun　的　javah），应用于前面在JNI　例子里使用的　Java　类文件　ShowMsgBox。
/* DO　NOT　EDIT
automatically　generated　by　msjavah */
#include
#pragma　warning（disable：4510）
#pragma　warning（disable：4512）
#pragma　warning（disable：4610）
struct　Classjava_lang_String；
#define　Hjava_lang_String　Classjava_lang_String
/* Header　for　class　ShowMsgBox */
#ifndef　_Included_ShowMsgBox
#define　_Included_ShowMsgBox
#define　HShowMsgBox　ClassShowMsgBox
typedef　struct　ClassShowMsgBox　｛
#include
long　MSReserved；
#include
｝　ClassShowMsgBox；
#ifdef　__cplusplus
extern　〃C〃　｛
#endif
__declspec（dllexport）　void　__cdecl
ShowMsgBox_ShowMessage　（struct　HShowMsgBox　*；
struct　Hjava_lang_String　*）；
#ifdef　__cplusplus
｝
#endif
#endif /*　_Included_ShowMsgBox　*/
#pragma　warning（default：4510）
660　
…………………………………………………………Page　662……………………………………………………………
#pragma　warning（default：4512）
#pragma　warning（default：4610）
除可读性较差外，代码里还隐藏着一些技术性问题，待我一一道来。
在RNI　中，固有方法的程序员知道对象的二进制布局。这样便允许我们直接访问自己希望的信息；我们不必　
象在JNI　里那样获得一个字段或方法标识符。但由于并非所有虚拟机都需要将相同的二进制布局应用于自己　
的对象，所以上面的固有方法只能在Microsoft　JVM　下运行。
在JNI　中，通过JNIEnv　自变量可访问大量函数，以便同JVM　打交道。在　RNI　中，用于控制JVM　运作的函数变　
成了可直接调用。它们中的某一些（如控制异常的那一个）类似于它们的　JNI　“兄弟”。但大多数RNI　函数　
都有与JNI　中不同的名字和用途。
JNI　和　RNI　最重大的一个区别是“垃圾收集”的模型。在　JNI　中，垃圾收集在固有方法执行期间遵守与Java　
代码执行时相同的规则。而在　RNI　中，要由程序员在固有方法活动期间自行负责“垃圾收集器”器的启动与　
中止。默认情况下，垃圾收集器在进入固有方法前处于不活动状态；这样一来，程序员就可假定准备使用的　
对象用不着在那个时间段内进行垃圾收集。然而一旦固有方法准备长时间执行，程序员就应考虑激活垃圾收　
集器——通过调用GCEnable（）这个RNI　函数（GC　是“Garbage　Collector”的缩写，即“垃圾收集”）。
也存在与全局句柄特性类似的机制——程序员可利用可保证特定的对象在　GC　活动期间不至于被当作“垃圾”　
收掉。概念是类似的，但名称有所差异——在　RNI　中，人们把它叫作GCFrames　。
A。4。1　RNI　总结
RNI　与　Microsoft　JVM　紧密集成这一事实既是它的优点，也是它的缺点。RNI　比JNI　复杂得多，但它也为我们　
提供了对JVM　内部活动的高度控制；其中包括垃圾收集。此外，它显然针对速度进行了优化，采纳了C　程序　
员熟悉的一些折衷方案和技术。但除了微软的　JVM　之外，它并不适于其他　JVM。
A。5　Java/　集成
（以前称为OLE）代表微软公司的“组件对象模型”（ponent　Object　Model　），它是所有ActiveX　技　
术（包括ActiveX　控件、Automation　以及ActiveX　文档）的基础。但 还包含了更多的东西。它是一种特　
殊的规范，按照它开发出来的组件对象可通过操作系统的专门特性实现“相互操作”。在实际应用中，为　
Win32　系统开发的所有新软件都与　有着一定的关系——操作系统通过 对象揭示出自己的一些特性。　
由其他厂商开发的组件也可以建立在　的基础上，我们能创建和注册自己的　组件。通过这样或那样的　
形式，如果我们想编写　Win32　代码，那么必须和 打交道。在这里，我们将仅仅重述 编程的基本概　
念，而且假定读者已掌握了　服务器（能为 客户提供服务的任何　对象）以及 客户（能从　
服务器那里申请服务的一个　对象）的概念。本节将尽可能地使叙述变得简单。工具实际的功能要强大得　
多，而且我们可通过更高级的途径来使用它们。但这也要求对 有着更深刻的认识，那已经超出了本附录　
的范围。如果您对这个功能强大、但与不同平台有关的特性感兴趣，应该研究　和微软公司的文档资料，　
仔细阅读有关Java/　集成的那部分内容。如果想获得更多的资料，向您推荐　Dale　Rogerson　编著的　
《Inside　》，该书由　Microsoft　Press　于　1997　年出版。
由于　是所有新型　Win32　应用程序的结构核心，所以通过Java　代码使用（或揭示）　服务的能力就显得　
尤为重要。Java/　集成无疑是　Microsoft　Java　编译器以及虚拟机最有趣的特性。Java　和　在它们的模　
型上是如此相似，所以这个集成在概念上是相当直观的，而且在技术上也能轻松实现无缝结合——为访问　
，几乎不需要编写任何特殊的代码。大多数技术细节都是由编译器和／或虚拟机控制的。最终的结果便是　
Java　程序员可象对待原始Java　对象那样对待 对象。而且 客户可象使用其他 服务器那样使用由　
Java　实现的　服务器。在这里提醒大家，尽管我使用的是通用术语“”，但根据扩展，完全可用Java　
实现一个ActiveX　Automation　服务器，亦可在Java　程序中使用一个ActiveX　控件。
Java　和　最引人注目的相似之处就是　接口与　Java　的“interface”关键字的关系。这是接近完美的一　
种相符，因为：
■　对象揭示出了接口（也只有接口）
■　接口本身并不具备实施方案；要由揭示出接口的那个　对象负责它的实施
■　接口是对语义上相关的一组函数的说明；不会揭示出任何数据
■　类将　接口组合到了一起。Java　类可实现任意数量的　Java　接口。
■　有一个引用对象模型；程序员永远不可能“拥有”一个对象，只能获得对对象一个或多个接口的引　
用。Java　也有一个引用对象模型——对一个对象的引用可“造型”成对它的某个接口的引用。
661　
…………………………………………………………Page　663……………………………………………………………
■　对象在内存里的“生存时间”取决于使用对象的客户数量；若这个数量变成零，对象就会将自己从内　
存中删去。在Java　中，一个对象的生存时间也由客户的数量决定。若不再有对那个对象的引用，对象就会等　
候垃圾收集器的处理。
Java　与　之间这种紧密?