JNI

Scenario:
New functionality needs to be added to a legacy customer account system written in C++.
There are plans to port this to java in the future.
The code of the legacy system is available.

Possible architecture:
Write the new functionality in a java application.
Wrap the legacy functionality using JNI. Connect to the wrapped methods via RMI.

Pros:
Quite fast. Works also the other way around: you can make the java code accessible by the native code.

Cons:

The existing system needs to run in process. So if the native system crashes, the java application crashes.

Coupling a java application to a native library creates the risk of losing two benefits of the Java platform:

• Portability to multiple host environments. It will be necessary to recompile the part of the application written in native code.
• Native languages such as C or C++ are not type safe. Therefore, java applications are subject to security checks before invoking JNI features.

Alternatives

• Communicate with the native application through a TCP/IP connection
• Connect to a legacy database through the JDBC API
• Make use of distributed object technologies such as the Java IDL API

JNI
Java Native Interface
Allows java to communicate with native code, such as C, C++ and assembly.
Basically, in this technique, you create a wrapper around a native method.

Note
The objective here is legacy connectivity, but usually, JNI is used in scenarios where the Java API does not support certain host-dependent features (e.g. file operations) or when the application needs to enhance speed using the faster native code (such as 3D rendering).