本原接口（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 <native.h>
#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 <pshpack4.h>
  long MSReserved;
#include <poppack.h>
} 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)
#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。