1016页程序
除可读性较差外,代码里还隐藏着一些技术性问题,待我一一道来。
在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/COM集成
COM(以前称为OLE)代表微软公司的“组件对象模型”(Component Object Model),它是所有ActiveX技术(包括ActiveX控件、Automation以及ActiveX
文档)的基础。但COM还包含了更多的东西。它是一种特殊的规范,按照它开发出来的组件对象可通过操作系统的专门特性实现“相互操作”。在实际应用中,为Win32系统开发的所有新
软件都与COM有着一定的关系——操作系统通过COM对象揭示出自己的一些特性。由其他厂商开发的组件也可以建立在COM的基础上,我们能创建和注册自己的COM组件。通过这样或那样的形式,如果我们想编写Win32代码,那么必须和COM打交道。在这里,我们将仅仅重述COM编程的基本概念,而且假定读者已掌握了COM服务器(能为COM客户提供服务的任何COM对象)以及COM客户(能从C
OM服务器那里申请服务的一个COM对象)的概念。本节将尽可能地使叙述变得简单。工具实际的功能要强大得多,而且我们可通过更高级的途径来使用它们。但这也要求对COM有着更深刻的认识,那已经超出了本附录的范围。如果您对这个功能强大、但与不同平台有关的特性感兴趣,应该研究COM和微软公司的
文档资料,仔细阅读有关Java/COM集成的那部分内容。如果想获得更多的资料,向您推荐Dale Rogerson编著的《Inside COM》,该书由Microsoft Press于1997年出版。
由于COM是所有新型Win32应用程序的结构核心,所以通过Java代码使用(或揭示)COM服务的能力就显得尤为重要。Java/COM集成无疑是Microsoft Java编译器以及虚拟机最有趣的特性。Java和COM在它们的模型上是如此相似,所以这个集成在概念上是相当直观的,而且在技术上也能轻松实现无缝结合——为访问COM,几乎不需要编写任何特殊的代码。大多数技术细节都是由编译器和/或虚拟机控制的。最终的结果便是Java程序员可象对待原始Java对象那样对待COM对象。而且