To JNI or not to JNI?
Demetrius L. Davis
Abstract
The combination of computation-intensive algorithms and steep
performance requirements typically implies the use of a native
programming language such as C, C++ or FORTRAN.
Although Java provides a robust API and a wide developer
base, the slower execution times of interpreted Java bytecodes
as compared to compiled C++ classes often eliminate Java as
a candidate platform for high-performance applications.
The Java Native Interface (JNI) offers an attractive solution to
this problem – computation-intensive operations may be coded
in a native programming language and then executed within a
Java application framework. In theory, JNI applications
provide the speed of native language implementations in
critical areas and the platform independence of Java for the
remaining sections of the application.
This paper initially examines the advantages and
disadvantages of a JNI implementation and shows how the JNI
implementation performs against an equivalent all-Java
implementation of a computationally intensive algorithm. The
results of this research effort will assist software developers in
identifying situations for which JNI is a viable or preferred
option.
Background
It is a generally accepted principle that a compiled C++ class
executes faster than an equivalent Java bytecode version. This
hypothesis is well-documented and rarely challenged in
situations where the Java implementation is interpreted by a
Java Virtual Machine (JVM). Consequently, native languages
such as C++ are regularly selected over Java as the preferred
programming platform for high-performance computing (HPC)
and scientific computing projects. The general opinion is that
Java is a slow, interpreted language which is incapable of
executing computationally complex and intensive algorithms
within an acceptable period of time. This perception is now
being challenged with the current generation of Java native
compilers and optimization options. Under certain scenarios,
Java compilers can produce native codes which perform at or
near the level of equivalent C and C++ routines [2, 3].
Currently, only one option provides the Java developer
community with the potential to combine the performance and
legacy of the lower-level programming languages (C, C++,
assembly) with the attractive features of Java (i.e., robust API,
garbage collection and platform independence): the Java Native
Interface (JNI). JNI is a Java API which permits native codes
to be “wrapped” in a Java class and executed within a Java
application framework. In essence, JNI serves as a bridge
between Java and lower-level languages such as FORTRAN,
C, and C++.
Like most software architectures, high performance
applications can be designed and developed in a modular
fashion. Critical sections where complex mathematical, search-
20th Computer Science Seminar
SC3-T2-1
based, or memory-intensive operations are performed may be
compartmentalized and classified as ordinary software
components. Once in component form, the developer can
determine which components perform CPU-intensive tasks and
select those components as candidates to be developed in a
native programming language. By doing this, the application
framework remains intact and the developer can outsource the
execution of components as necessary.
Some studies have shown that, under certain conditions,
compiled Java routines can perform near or at the level of some
lower level languages [2]. These benchmarks are tempered by
other research efforts which expose Java’s performance
shortcomings in I/O operations and parallel computing [1, 6, 9].
Nonetheless, there is a prevailing consensus that Java will
eventually outperform its predecessors [8].
This research effort will assess the suitability of a JNI
implementation as a measure for porting an algorithm written
and thoroughly tested in a native language into a Java
framework. This practice is common in situations when an
algorithm is customized or optimized for a specific domain or
problem set. In these cases, developing an equivalent solution
in Java may not be possible or feasible. A JNI solution also
permits the algorithm to maintain connections to native
libraries and classes.
For more practical purposes, this research effort will assist Java
developers in identifying situations which are amenable to a
JNI implementation. Of course, this research does not replace
the need to evaluate all of the deciding factors typically
associated with a software development project. The objective
of this research effort is to assess the tradeoffs of JNI and Java
implementations to determine 1) if and when JNI should be
employed, and 2) at which point is a pure Java implementation
a better solution performance-wise.
At the time of this writing, it is understood that Java is not able
to compete head-to-head with native languages in terms of
sheer performance. Nonetheless, a pure Java solution may be
feasible if the computationally intensive routines are identified,
isolated and then developed with a native programming
language. The remaining elements of the application – the
sections with comparable performance benchmarks – will be
developed in Java. As any software component, the high-
performance native routines can be added to the Java
application by interfacing with the Java framework via JNI.
The information technology community will be best served by
providing clear and concise research results which are
applicable across multiple domains and implementations.
Increased productivity, return-on-investment (ROI), and
reusable software are important to both developers and
management. The results attained in this research effort will
place time-saving and money-saving information at the
fingertips of the reader. Deciding between forgoing a Java
solution due to pivotal legacy software and wrapping the legacy
routines in Java will become a simpler and shorter task.
Methodology
The goal of this research effort is to determine if a
computationally intensive native routine, wrapped in Java,
would yield comparable performance to an equivalent all-Java
implementation. Complex math operations, sort and search
algorithms are examples of computation-intensive activities
which are typically written and compiled in a lower-level
language such as C, C++, or FORTRAN. For this study, two
robust algorithms were selected and implemented as self-
contained components which will be called from a Java
program.
Tests. A series of benchmark tests were scheduled to measure
the average execution times of the two test algorithms, each
written in Java and C++. The start and end times were
collected from each benchmark test; results related to memory
management, software quality, I/O performance, level-of-
effort, and program size (in SLOCs) were not recorded. To
increase accuracy among all test runs, the tests were executed 3
times and the average execution time was recorded.
Each of the selected algorithms operates on an array of integer
values. To assess the impact of array sizes on the performance
of the Java and JNI implementations, each program run was run
using three different array sizes: 250, 1000, and 10000. This
range of array sizes was selected to reveal any thresholds where
performance suddenly improved or diminished.
In addition to varying the array sizes, the number of iterations
was varied in order to exacerbate the impact of any overhead
associated with the startup or execution of either approach. It
is understood that the startup overhead associated with JNI is a
primary deterrent for developers concerned with performance.
Consequently, each program was executed with iteration counts
of 250, 1000, and 3500.
Languages. JNI supports several different lower-level
languages. For this study, C++ was selected as the native
programming language due to its large customer base and
reputation for high-speed computations. The C++ classes were
compiled with MS Visual C++ 6.0.
Programmers. JNI programming naturally requires
proficiency in more than a single programming language. To
minimize differences in programmer skill levels, programming
methodologies, and programming language features,
implementations of the target algorithms were obtained from
the public domain. The performance of the surrounding
software architecture of each candidate solution was not under
evaluation; only the time spent executing the algorithm was
recorded.
Algorithms. Two computation-intensive algorithms as used
for this study: an implementation of the Heapsort algorithm
which encompasses sorting and large-array operations and a
Discrete Fast Fourier Transform (FFT) algorithm which
exposes Java’s performance in numerical analysis and complex
mathematical computations. [4] and [7] provided complete
Java and C++ versions of the selected algorithms.
Platform/OS. All benchmark tests were run on the same
machine – a 2.6 GHz Pentium 4 computer with 512 MB RAM.
The test machine was a Windows XP platform running the Java
SDK version 1.4.1. Previous benchmarking efforts have shown
that JVM and compiler performance across multiple computing
platforms can vary widely [2, 9]. Since a single test platform
20th Computer Science Seminar
SC3-T2-2
and environment was used for this study, accuracy of the
experiment was not jeopardized.
Program architecture. Three Java classes comprise the
general program architecture that was used for the benchmark
runs. The first class, main, contains the top-level main()
routine and initializes the managing class Benchmark (see
Code example 1). The main() class then obtains the
minimum set of algorithm parameters from the user via the
array of string arguments passed in to the main() method.
The main class passes the user-supplied input values to the
run() method of the Benchmark class.
public class main {
public static void main(String[] args) {
int algIndex = Integer.parseInt(args[0];
Boolean runJNI =
Boolean.valueOf(args[1]);
int iterCnt = Integer.parseInt(args[2]);
(new Benchmark()).run(algIndex,
runJNI.booleanValue(), iterCnt);
}
}
Code example 1: main.java
Inside the Benchmark class (see Code example 2), the start
and stop times for the program execution are stored; the
Benchmark class is also responsible for initializing and
executing the appropriate algorithm. The algIndex input
parameter designates which of the algorithm types will be used
for the current operation. The runJNI parameter states
whether or not the JNI version of the algorithm will be
employed for the current run. The iterCount parameter
specifies the number of times the algorithm is to be executed.
The execTime parameter – the difference between the start
time and end time – will be calculated and outputted to
standard output.
public class Benchmark
{
public void run(int algIndex, boolean
runJNI, int iterCount)
{
// Initialize appropriate Algorithm object
Algorithm alg =
AlgorithmFactory.getAlgorithm(algIndex,
runJNI);
Calendar cal = Calendar.getInstance();
long t1 = cal.getTimeInMillis();
for (int i=0; i<iterCount; i++) alg.run();
long t2 = cal.getTimeInMillis(); // end
time
long execTime = t2 - t1; // execution time
}
}
Code example 2: Benchmark.java
Measurements
At the start of each execution, the current time was recorded as
the start time. Time is stored as the number of milliseconds
since January 1, 1970, 00:00:00 GMT.
Upon completion of each execution, the end time was captured
and recorded. The time difference between the start and end
times was recorded as the algorithm execution time. Each run
was performed three times in succession and the average program within a specific iteration count grouping (see Table
execution time was recorded and analyzed. 1). In this case, the similarity of the execution times across
such a considerable range of array sizes likely reflects the
Evaluation efficiency and speed of the sorting algorithm rather than the
JVM.
The results obtained from the algorithm runs were impressive
and conclusive. The following subsections present the results Another interesting observation is the consistent curvature seen
for each set of benchmark runs. A final summary and analysis in each of the three line charts shown in Figures 1, 2, and 3.
concludes the section. The intent of the multiple array sizes was to agitate any
performance inhibitors such as excessive overhead during start-
Heapsort up and JNI method invocation. If there were significant
overhead issues attributed to JNI implementations, then a larger
The pure Java implementation of the Heapsort algorithm
number of method invocations would necessarily impose larger
revealed that the iteration count has a significantly greater
performance delays. The similarities among each of the line
impact on execution time than the array size. This assertion is
charts suggest that the impact of start-up and method
evident considering the near identical results for the pure Java
invocation overhead is sufficiently negligible.

Table 1 – Heapsort results (milliseconds)

Number of iterations
250 1000 3500
Array size Array size Array size
250 1000 10000 250 1000 10000 250 1000 10000
Heapsort (ms)
Java 40 40 50 140 140 140 400 400 400
JNI 30 30 110 30 60 390 60 150 1310
FFT (ms)
Java 741 4577 49290 2924 18286 197154 10165 63942 689381
JNI 742 4576 49661 2904 18196 197805 10234 63912 694048

Clearly, the most telling results from the Heapsort runs can be count increases, the JNI program further widens the performance
seen in Figures 4, 5, and 6. Unlike the iteration count-based line gap when the array elements do not exceed 1000.
charts, the bar charts view the data according to the array sizes.
The nearly identical results for the pure Java implementation At some point beyond 1000 elements, the JNI implementation
further the assertion that the iteration count plays a more takes an enormous performance hit. The cause of the sudden
significant role than the array size. While the pure Java degradation in execution speed is likely attributable to memory
implementation shows little to no variation, the JNI limitations of the test computer than to an inherent lack of
implementation yields a pronounced curve as the array size scalability of JNI. Nonetheless, the figures in Appendix A
increases. Up to 1000 integers, the JNI implementation expose an obvious shortcoming of JNI: heavyweight objects or
outperformed the pure Java version; actually, as the iteration large arrays of primitive data types have a noticeably adverse
effect on the application performance.

Heapsort (sample size=250) Heapsort (sample size=1000) Heapsort (sample size=10000)

450 450 1400

400 400 1200

350 350
1000
300 300
Time (ms)
Time (ms)

Time (ms)

250 250 800

Java Java Java
200 JNI 200 JNI JNI
600

150 150
400
100 100
200
50 50

- - 0
250 1000 3500 250 1000 3500 250 1000 3500
Iteration count Iteration count Iteration count

Figure 1 – Heapsort (250 elements) Figure 2 – Heapsort (1000 elements) Figure 3 – Heapsort (10000 elements)

20th Computer Science Seminar

SC3-T2-3
 Heapsort (250 iterations)
120
100
80
Time (ms)
Time (ms)
60 Java
JNI
40
20
0 0
250 1000 10000
Array size
Figure 4 – Heapsort (250 iterations) Figure 5 – Heapsort (1000 iterations)
Discrete Fast Fourier Transform (FFT)
The results from the execution of the FFT algorithm offer
additional insight into the differences between a pure Java and a
C++ routine implemented via the JNI. The FFT routine involves
more mathematical computations and takes a sizeable amount of
time to execute as compared to the Heapsort algorithm. This
disparity served two purposes: the two Java programs executed a
more computationally intensive algorithm and consequently, each
implementation to handle extensive math computations was
sufficiently tested.
The range of execution times between the Heapsort and FFT runs
were significant. Nonetheless, there is profound symmetry
between the execution times of the two algorithms (see Table 2).
Moreover, the execution times between the Java and JNI
implementations of the FFT algorithm are eerily similar. Unlike
the highly efficient Heapsort algorithm, the necessary processing
time for the FFT algorithm outweighed any overhead impact
generated by JNI function calls. As suspected, the recorded times
of a less-than-efficient algorithm reflect more of the algorithm
performance and efficiency than the performance of the
programming platform.
In addition to the similarity in the execution times, the rate of
execution is also nearly identical throughout every run and
iteration count grouping. Regardless of array size or number of
iterations, every FFT calculation averaged 2.9 milliseconds. This
form of consistent performance indicates a high probability that
the implementation, whether pure Java or part Java, will not
adversely affect the scalability of this type of algorithm.
Conclusion
High performance applications are traditionally developed in
native programming languages such as C, C++ and FORTRAN.
The movement towards Java has been hindered in the high
performance computing domains due to the slower, interpretive
nature of the JVM. The need for computing speed by select
domains have resulted in the older, compiled languages
maintaining a foothold on most software development and
maintenance efforts. Although developers of real-time,
embedded, simulation, graphics and scientific applications are
attracted to Java’s platform independence, robust API, supporting
technologies, and extensive developer base, the fear of degraded
performance in time-critical applications have slowed the
adoption of Java as a primary programming language and
computing platform.
Moreover, the cloud of uncertainty that hovers over the Java
Native Interface (JNI) deters software developers from
considering a JNI solution for their existing legacy applications.
Heapsort (1000 iterations) Heapsort (3500 iterations)
400 1400
350 1200
300
1000
250
Time (ms)
800
200 Java Java
600
150 JNI JNI
400
100
50 200
0
250 1000 10000 250 1000 10000
Array size Array Size
Figure 6 – Heapsort (3500 iterations)
This research effort has uncovered several interesting findings.
First, JNI is definitely a viable option for handling algorithms
that manipulate a small to moderate-sized set of primitive data
types. In such cases, the time required to “wrap” a native routine
within a JNI framework is minimal compared to transcribing the
native routine into a comparable Java version. The consistency
recorded by the pure Java implementation indicates that, as the
need for larger sized or a larger number of elements arises, a pure
Java re-implementation of the native code routine is
recommended.
Secondly, the overall performance of either Java implementation
is greatly influenced by the efficiency and performance of the
underlying algorithm. Performance can be markedly improved if
an algorithm is optimized for performance and a small memory
footprint. Such constructs as nested loops, recursion, and
excessive object instantiations will result in a drastic decrease in
response times. This assertion is supported by the data collected
from the Heapsort algorithm runs. The efficiency of the Heapsort
algorithm, which executes in less than O(n log n) time, is a major
contributor towards the relatively fast times recorded in Table 1.
Lastly, the performance of the pure Java implementations as the
iteration count increases is amazingly linear. In the executions of
the Discrete Fast Fourier Transform algorithm, for array
containing 250 integers, the algorithm maintained a 2.9-
millisecond average over all three iteration count groups. The
Heapsort algorithm registered extremely minimal variations.
This conclusion establishes a pure Java implementation as a
lower risk option when the variable parameters of the application
are not readily known.
Future Work
The boundaries of this research effort can be expanded in many
ways. Accuracy can be increased by evaluating a larger cross-
section of algorithms, compilers, platforms and operating
systems. Moreover, a comparative analysis of I/O performance
(i.e., file streams, network and database connectivity) as it relates
to JNI implementations would refine this research effort by
identifying more specific scenarios in which a hybrid JNI
solution will outperform a 100% Java implementation.
Liang [4] states that the overhead associated with the transfer of
heavyweight objects such as large arrays and strings is “not
acceptable” over an extensive sequence of function calls. Similar
to this study, a future research effort can zero in on the specific
scenario under which the use of heavyweight objects negates the
benefit of using a JNI implementation. These types of research
activities will aid the software developer considerably in 1)
clearly understanding and knowing the pros and cons of JNI, and
2) providing a map for when to employ (and when not to employ)
a JNI-based solution.
20th Computer Science Seminar
SC3-T2-4
References
[1] Dickens, P. and R. Thakur, “An Evaluation of Java’s I/O
Capabilities for High-Performance Computing,”
Proceedings of the ACM 2000 Conference on Java Grande,
2000, pp. 26-35.
[2] Kazi I., H. Chen, B. Stanley, and D. Lilja, “Techniques for
Obtaining High Performance in Java Programs”, ACM
Computing Surveys, vol. 32, issue 3, September 2000, pp.
213-240.
[3] Kurzyniec, D. and V. Sunderam, “Efficient Cooperation
between Java and Native Codes – JNI Performance
Benchmark,” The 2001 International Conference on
Parallel and Distributed Processing Techniques and
Applications (PDPDA), 2001.
[4] Liang S., The Java Native Interface, Sun Microsystems Inc,
1999.
[5] Mathew J., P. Coddington, and K. Hawick, “Analysis and
Development of Java Grande Benchmarks”, Proceedings of
the ACM 1999 Conference on Java Grande, 1999, pp. 72-
80.
[6] Prechelt L., “Technical Opinion: Comparing Java vs.
C/C++ Efficiency Differences Interpersonal Differences,”
Communications of the ACM, vol. 42, issue 10, October
1999, pp. 109-112.
[7] Press W., S. Teukolsky, W. Vetterling, and B. Flannery,
Eds., Numerical Recipes in C++: The Art of Scientific
Computing, Cambridge University Press, 1992.
[8] Reinholtz K., “Java will be faster than C++”, ACM
SIGPLAN Notices, pp. 25-28.
[9] Sangappa S., K. Palaniappan, and R. Tollerton,
“Benchmarking Java against C/C++ for Interactive
Scientific Visualization,” Proceedings of the 2002 joint
ACM-ISCOPE Conference on Java Grande, 2002, p. 236.

20th Computer Science Seminar

SC3-T2-5