Evaluating the Java Native Interface (JNI): Data Types and Strings

Introduction

The Java Native Interface (JNI, 2014) aims to provide interoperability between Java code running on Java Virtual Machine (JVM) and code written in other programming languages like C, C++, assembly, python and others. It is typically used for utilizing certain platform depended features, for reusing existing libraries and for speeding up time critical execution of applications. Using the JNI, developers implement Java classes that are extended with native methods and linked dynamically. This is possible, for instance, by using shared objects, as in UNIX systems or Dynamic-Link Library (DLL) extensions on Windows systems. Today, with the increasing amount of applications and disruptive based innovative services like mobile applications, cloud platforms, Internet of Thing (IoT) sensor protocols and development suites, the utilization of the JNI concept becomes once more essential (Sun et al., 2013). According to Dawson et al. (2015), JNI can be a key element for leveraging existing code assets in a service-oriented architecture (SOA) or cloud-based system. JNI is crucial for utilizing and interacting with libraries specific to platforms of embedded systems as it enables access to faster execution of native programs (Lee et al., 2011). This will offer a significant advantage by speeding up the development process, avoiding the reproduction of already developed code and thereby, increasing performance (Chandrian, 2011)

Using JNI, a Java application invokes native methods, submits parameters and obtains results after the native method has finished processing. The latter can both create and invoke operations on existing Java objects to: (a) create, update and inspect Java objects, (b) get any primitive data types or objects, (c) return either Java primitive data types or objects back to the Java program, (d) call Java instance or class methods, pass it the required parameters and get the results back when the method completes, (e) catch and throw Java exceptions and, (f) implement synchronization to support multithreaded access to a running JVMs.

There are various ways in which a Java application can communicate with a native application. These include using a TCP/IP connection, and via Inter-Process Communications (IPC) mechanisms etc. (Stenman & Sagonas, 2009). A Java application may also connect to a legacy system via a database using standard Java API, or by utilizing distributed objects such as RPC or Java IDL API (Sperko, 2003). However, in the aforementioned cases the native code resides in different processes. Having said that, the contribution of this work focuses on exploring JNI features that are essential for cases in which a Java application will need to communicate with native code that resides in the same process (Android M Developer, 2015, Liang, 1999). This has been proposed as an efficient solution for mobile application platforms, such as the Android platform, to load code from dynamic shared libraries. In particular, from the perspective of disruptive technologies, the benefits of using JNI includes the fact that both the calling program and the called program share the same process, while still allowing other methods to start new processes. By this method JNI provides faster calls and consumes less resources.