Java Reference
In-Depth Information
task at hand and if that functionality is really unavailable in the Java API. As
the API has grown, access to almost everything that might be needed from the
underlying operating system has become available through standard Java API
classes. Another important consideration militating against the use of JNI is that
accessing native language features voids many of the security and safety features
of Java. Using a native language that permits pointer manipulation, buffer or array
overruns, and memory leaks carries many risks.
One oft-cited reason for using JNI is performance - other languages are
thought to be “faster.” The perceived lack of performance of modern-day Java is
often just that - perception - rather than reality. We urge any developer to demon-
strate to himself that Java's platform independent performance is insufficient to
the task at hand before making the leap to platform
de
pendence and JNI.
A more-defensible reason for using JNI is to gain access to legacy code.
Some legacy applications, particularly large scientific calculations, represent
many years of effort, development, and debugging. Rewriting and re-debugging
such codes in Java could be prohibitively time consuming and expensive. Since
legacy codes are likely already tied to a specific platform or operating system,
once a design decision is made to use the legacy code in the first place, then the
use of JNI probably does not add to the platform dependency of the legacy code.
In such cases, using JNI to access a legacy calculation engine in a distributed
application makes good sense and can provide the best of both worlds - a rich and
portable Java user interface for the client, and a highly developed and debugged
calculation engine on the server.
22.2 What is JNI?
Just what is “native” about the Java Native Interface? When using JNI, a Java
program makes a method call to a method whose implementation is written in
a native language. Such a method is called a
native
method. To the calling Java
program, it's just a regular method call, complete with Java primitive or object
parameters and/or return types. In fact, the calling code has very little evidence
that the method is actually implemented in another language, and the calling
code doesn't really care. Nor should it care. Someday the native method could be
re-implemented in Java, and the calling program should not have to make exten-
sive changes to use the new implementation.
When a Java program makes a native method call, some special libraries have to
get involved to route the native method call to the native language implementation.
Those libraries are necessarily both system dependent and language dependent -
i.e. they have to be written for the particular operating system and native language
in use. Sun's J2SE implementations for Solaris, Linux, and Windows include the
JNI libraries for those platforms for the C and C
languages. Other implemen-
tations of J2SE on other platforms must also provide C and C
++
++
JNI libraries
Search WWH ::
Custom Search