Native Interface (JNI) is a mechanism that can be used to
establish communication between native language programs and the
Java virtual machine. The documentation for JNI and the technical
literature on JNI deal extensively with interactions between the
JVM and C/C++ code. The Java SDK even provides a utility to
generate a header file to facilitate calling C/C++ programs from
Java code. However, there is hardly any mention of Java and
assembly language code working together. In an
earlier article I showed how assembly language programs can be
called from Java applications. Here I deal with the technique for
invoking Java programs from an ASM process through a demo
application that calls a Java method from assembly language code.
The Java method brings up a Swing
JDialog to show that
it has, indeed, been launched.
JNI is essential to the implementation of Java, since the JVM
needs to interact with the native platform to implement some of its
functionality. Apart from that, however, use of Java classes can
often be an attractive supplement to applications written in other
languages, as Java offers a wide selection of APIs that makes
implementation of advanced functions very simple.
Some time ago, I was associated with an application to collect
real-time data from a number of sources and save them in circular
buffers so that new data would overwrite old data once the buffer
got filled up. If a designated trigger event was sensed through a
digital input, a fixed number of data samples would be saved in the
buffers so that a snapshot of pre- and post-trigger data would be
available. The original application was written in assembly
language. After the application was used for a few months, it was
felt that it would be very useful to have the application mail the
snapshots to authorized supervisors whenever the trigger event
occurred. Of course, it would have been possible to write this
extension in assembly, but the team felt that in that particular
instance it was easier to write that extension in Java and hook it
up with the ASM program. As I had earlier worked with ASM-oriented
JNI, I knew this could be done and, indeed, the project was
implemented quickly and successfully.
I am sure there are many legacy applications written in assembly
language that could benefit from such add-ons. However, it is not
only for old applications in need of renovation that JNI can prove
useful. Although it may seem unlikely to some of us, assembly
language is still used for writing selected portions of new
programs. In an
article published not very long ago, the author says, "I have
found that many of Sun's partners still use assembly language in
their products to ensure that hot code paths are as efficient as
possible. While compilers are able to generate much more efficient
code today, the resulting code still doesn't always compete with
hand-coded assembly written by an engineer that knows how to
squeeze performance out of each microprocessor instruction.
Assembly language remains a powerful tool for optimization,
granting the programmer greater control, and with judicious use can
enhance performance." Clearly, in such "mixed language"
applications the ability to use Java with ASM can be useful.
Note that the technique shown here can also be used to call Java
code from languages other than ASM. If
rewritten as a .dll, code written in FORTRAN, for instance,
can link to it and call a Java method.
I have used JNI with legacy ASM code in two ways:
These enhanced applications have run on Windows 2000 and XP. The
Java versions used were 1.3, 1.4, and 1.6. In all cases the
applications worked smoothly.