Content area
With the development of programming languages, Java has become one of the most prominent high-level and object-oriented programming languages. To provide access to memory management and interact with native coding resources (C, C++, etc.), two packages, sun.misc.Unsafe and Java Native Interface (JNI), have been imported to process data and manage memory since Java 1.1 and Java 1.2. However, as Java becomes more complex and mature in higher versions, both packages expose danger and brittle code that was never intended to be used outside of the Java Development Kit (JDK). For instance, after JDK 9, new methods (java.lang.invoke.VarHandle, java.nio.ByteBuffer, etc.) perform better in memory management compared to sun.misc.Unsafe; JNI is brittle and dangerous with respect to calling native libraries and processing native data. To address this problem, in recent years, JDK developers have proposed a new API called Foreign Function and Memory API (FFM API). It uses a new programming style to manage code and memory. To study the differences between the FFM API and two selected representative APIs (sun.misc.Unsafe and JNI), I performed an empirical study by exploring two transformation cases (sun.misc.Unsafe to FFM API and JNI to FFM API); each case include several samples. Based on the collected data from transformation cases, the FFM API has advantages in maintaining the stability of data processing, simplifying the coding structure, and improving the efficiency of compiling performance. However, the FFM API has many unexpected problems (compatibility errors, etc.) when the application’s code is complicated and sizable.