The alternative to JNI: How to use Jnr to access Java external function interfaces (Jnr-ffi)

1. Jnr Brief Introduction

Following "The alternative to JNI-using JNA to access the Java external function interface", we know that JNI is becoming less popular, and JNI is a standard programming interface for writing Java native methods and embedding Java virtual machines in local applications. It manages the boundaries between the JVM and the unmanaged local environment, providing data marshalling and object lifecycle management protocols.

According to the Jep (JDK enhancement proposal) 191,JNI is the most painful for developers in the following ways:

Developers are required to write C code, which means they need expertise in a world completely different from Java.

Because developers must have some knowledge of how the JVM manages memory and code, typical C and Java developers typically do not have the expertise they need to use JNI.

Developers must be able to build code for each platform they want to support, or provide the right tools for end users to do the work.

JNI Library performance is usually poor compared to the same library bound to a local application.

JNI acts as an opaque security boundary. The JDK does not know what the functions in the library might call, or whether the code in the library can compromise the stability or security of the JVM.

So JNI creates local functions in a way that is not simple, resulting in libraries like Java Native Access (JNA) and Java Native Runtime (Jnr). Both JNA and Jnr are created based on JNI, and the Java Foreign Function Interface (FFI) defined by Jep 191 may be based on Jnr. Using the FFI API rather than JNI binding the code and memory will be a preferred way for developers.

The FFI API will provide the following features:

A metadata system that describes local library calls and local memory structures.

mechanism for discovering and loading local libraries.

A mechanism for binding a library/function or memory structure to a Java endpoint based on metadata.

Code for marshalling and reconciliation groups between Java data types and local data types.

The need for Java FFI has resulted in JNA and Jnr libraries. The JNA library is more widely used (see "Alternatives to JNI-use JNA to access Java external function interfaces"). The Jnr Library is more comprehensive because it implements different levels of abstraction, provides function and memory metadata, and abstracts library and function bindings. Jnr has been used heavily in JRuby projects and may be the basis for Jep 191.

The above paragraph comes from the description of Jep 191 (translated by reference (1)), which shows that although JNA is widely used, Jnr may be more trending, and perhaps in the near future Jnr-ffi (Jffi) will be built into the JDK as a standard interface for Java access to external functions. Therefore, it is very necessary to learn how to use Jnr.

The Jnr-ffi project is also hosted by GitHub, which is similar to JNA, but Jnr does not give the appropriate jar packs and needs to be packaged for our own use.

2. Jnr Project Packaging (Jnr-ffi.jar)--How to package the MAVEN project on GitHub

The first thing to be clear is that projects hosted on GitHub are typically built with MAVEN management, not eclipse/myeclipse, so if you want to download project source code directly from GitHub (Download Zip download) and then importing or copying it into eclipse is not a feasible way to pack. I did the same thing at the beginning, and found the project incomplete and missing some packages, so the jar package was not available.

To my surprise, the Jnr-ffi.jar package in the MAVEN official library is also incomplete, downloading is not available, and all the jnr packages in this place, I have tried, all incomplete, so can only pack their own.

Before packaging, you first need to download the complete source code, and then there are two ways of packaging into a jar file.

Package maven projects into eclipse

Package via maven Command MVN

There are two ways to be aware of these. People who are unfamiliar with Maven can take the first approach, easy to use. Familiarity with Maven is certainly recommended for packaging with the MVN command, but be aware that there are third-party dependencies, not a simple command to handle.

Package maven projects into eclipse

Note: Although Eclipse has a built-in MAVEN plug-in, it does not work very well, often with problems, it is recommended that you uninstall Eclipse's own Maven plug-in, and then install a Third-party m2eclipse plug-in, which currently has a valid installation address: http:// Download.eclipse.org/technology/m2e/releases, Help-install New software...-add repository installation through Eclipse.

After you have the MAVEN plug-in, the following are the specific steps to package:

(1) Download source from GitHub

This is actually very critical, because can not be "Download Zip" way directly from the GitHub Web page download, so that the source of downloads is missing a lot of J-dependent AR package, need to download the way git clone

git clone https://github.com/jnr/jnr-ffi.git

After downloading the project source code is under the current command line path.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/Java/