Chapter 9. The Jamaica Binary Interface

Table of Contents
Java Native Interface vs. Jamaica Binary Interface
Caveats when using JBI
Using JBI
Types used by JBI
Accessing Java Arrays in JBI
Accessing Java Object Fields in JBI
Calling Java Methods from JBI code
Throwing exceptioncs from JBI code

The Jamaica Binary Interface provides a fast and low-level mechanism to access native code from Java applications running on JamaicaVM.

Java Native Interface vs. Jamaica Binary Interface

The Jamaica Virtual Machine (JamaicaVM) provides two mechanisms for accessing non-Java (native) Code. The easiest and standard means to access native Code is via the Java Native Interface JNI (see [1]). JNI has been defined to be portable to very different Java Virtual Machine implementations. Most Java implementations consequently support JNI. Java applications that use native code via JNI can typically be ported to different virtual machines with minimal effort.

This flexibility, however, comes at a cost in performance. The complete abstractions from the garbage collector implementation and the object representation, which make JNI portable, can cause a significant run-time overhead.

The Jamaica Binary Interface instead is specific to the JamaicaVM. It avoids the additional runtime overhead, but it requires extreme care when native code is written. E.g., support for the garbage collector or thread synchronization falls under the responsibility of the developer of JBI code. Errors in these areas can have desastrous consequences such as too early recycling of objects or delayed thread preemption.

The Jamaica Binary Interface is used for the native code created by the compiler that is part of the Jamaica Builder and that is enabled by the command line options -compile or -useProfile. Consequently, calls native code that was written by the user using the JBI interface and that is called from within compiled Java methods is particularly efficient.

Notes

[1]

The Java Native Interface Specification, V1.0