Raw Native Interface (RNI)

Compared

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.

RNI

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.

There

are several notable differences between JNI and RNI. Below is the C header file

generated by

,

the Microsoft equivalent of Sun’s

,

applied to the

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)

Apart

from being less readable, there are more technical issues disguised in the

code, which we’ll examine.

In

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.

In

JNI, the

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.

One

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

RNI function.

There

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

s.

RNI
Summary

The

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.

|

|