Bruce Eckel’s Thinking in Java | Contents | Prev | Next |
to J/Direct, RNI is a fairly complex interface to non-Java code, but it’s
much more powerful. RNI is closer to the JVM than J/Direct, and this lets you
write much more efficient code, manipulate Java objects in your native methods,
and in general gives you a much higher degree of integration with the JVM
internal operations.
is conceptually similar to Sun’s JNI. Because of this, and because the
product is not yet completed, I’ll just point out the major differences.
For further information, please refer to Microsoft’s documentation.
are several notable differences between JNI and RNI. Below is the C header file
generated by
msjavah,
the Microsoft equivalent of Sun’s
javah,
applied to the
ShowMsgBox
Java class file used previously for the JNI example.
/* 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)
from being less readable, there are more technical issues disguised in the
code, which we’ll examine.
RNI, the native method programmer knows the binary layout of the objects. This
allows you to directly access the information you want; you don’t need to
get a field or method identifier as in JNI. But since not all virtual machines
necessarily use the same binary layout for their objects, the native method
above is guaranteed to run only under the Microsoft JVM.
JNI, the
JNIEnv
argument gives access to a large number of functions to interact with the JVM.
In RNI, the functions for controlling JVM operations are directly available.
Some of them, like the one for handling exceptions, are similar to their JNI
counterparts, but most of the RNI functions have different names and purposes
from those in JNI.
of the most remarkable differences between JNI and RNI is the garbage
collection model. In JNI, the GC basically follows the same rules during native
method execution that it follows for the Java code execution. In RNI, the
programmer is responsible for starting and stopping the Garbage Collector
during native method activity. By default, the GC is disabled upon entering the
native method; doing so, the programmer can assume that the objects being used
will not be garbage collected during that time. But if the native method,
let’s say, is going to take a long time, the programmer is free to enable
the GC, calling the
GCEnable( )
RNI function.
is also something similar to the global handles features – something the
programmer can use to be sure that specific objects will not be garbage
collected when the CG is enabled. The concept is similar but the name is
different: in RNI these guys are called
GCFrames.
RNI
Summary
fact that RNI is tightly integrated with the Microsoft JVM is both its strength
and its weakness. RNI is more complex than JNI, but it also gives you a high
degree of control of the internal activities of the JVM, including garbage
collection. Also, it is clearly designed for speed, adopting compromises and
techniques that C programmers are familiar with. But it’s not suitable
for JVMs other than Microsoft’s.