Raw Native Interface (RNI)

Bruce Eckel's Thinking in Java Contents | Prev | Next

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 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" {
__declspec(dllexport) void __cdecl 
ShowMsgBox_ShowMessage (struct HShowMsgBox *, 
  struct Hjava_lang_String *);
#ifdef __cplusplus
#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 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.

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 GCEnable( ) 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 GCFrames.

RNI Summary


  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Lenovo recommends Windows 8 Pro. "I dropped my laptop getting out of the taxi." This probably sounds familiar to most IT professionals. If your employees are traveling, you know their devices are in for a rough go. Whether it's a trip to the conference room or a convention out of town, any time equipment leaves a user's desk it is at risk of being put into harm's way. Stay connected at all times, whether at the office or on the go, with agile, durable, and flexible devices like the Lenovo® …

  • When individual departments procure cloud service for their own use, they usually don't consider the hazardous organization-wide implications. Read this paper to learn best practices for setting up an internal, IT-based cloud brokerage function that service the entire organization. Find out how this approach enables you to retain top-down visibility and control of network security and manage the impact of cloud traffic on your WAN.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date