Primitive Interface (RNI)

Compared to J/direct, Rni is a much more complex interface than non-Java code, but its functionality is also powerful. Rni is closer to the JVM than J/direct, which also enables us to write more efficient code that handles Java objects in native methods and enables closer integration with the internal operating mechanism of the JVM. The
Rni is conceptually similar to the jni of Sun Corporation. For this reason, and since the product has not been formally completed, I am only here to point out the major differences between them. For more information, refer to Microsoft's documentation. There are several compelling differences between the
Jni and Rni. The following is a list of C-header files generated by Msjavah (the Microsoft-provided Msjavah is functionally equivalent to Sun's Javah) and is applied to the Java class file Showmsgbox previously used in the JNI example.
 

/* Do not edit-automatically generated by Msjavah * * #include <native.h> #pragma warning (d
isable: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:451 2) #pragma warning (default:4610) 

In addition to the poor readability, there are some technical problems hidden in the code, to me one by one.
In Rni, programmers of intrinsic methods know the binary layout of objects. This allows us to access the information we want directly; we don't have to get a field or method identifier like we did in JNI. However, since not all virtual machines need to apply the same binary layout to their own objects, the above inherent method can only be run under the Microsoft JVM.
In Jni, a large number of functions can be accessed through jnienv arguments to deal with the JVM. In Rni, the functions used to control the operation of the JVM become callable directly. Some of them, such as the one that controls the exception, resemble their jni "brothers". But most rni functions have different names and uses for JNI.
One of the most significant differences between JNI and Rni is the "garbage collection" model. In Jni, garbage collection adheres to the same rules as Java code execution during inherent method execution. In Rni, the programmer is responsible for the start and stop of the garbage collector during the inherent method activity. By default, the garbage collector is inactive before it enters the intrinsic method, so that the programmer can assume that the intended object does not need to be garbage collected during that time period. However, once the inherent method is ready for long time execution, the programmer should consider activating the garbage collector-by calling Gcenable () the RNI function (GC is the abbreviation for "Garbage Collector", or "garbage collection").
There is also a mechanism similar to the global handle attribute--that programmers can use to ensure that certain objects are not collected as "garbage" during GC activity. The concept is similar, but the name is different--in rni, people call it gcframes.