按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
令里不规定想调用哪个版本，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 与 之间这种紧密�