JNI Limitations and Considerations

The Java language imposes certain limitations native code loaded into the JVM for use by JNI. These limitations have implications for how a component can operate, its reliability, and how it can be updated with new versions. Later sections describe how to best structure a component to minimize some of these limitations.

Versioning

One of the Java language restrictions on native code is that Java does not support loading multiple versions of the same native code library. Once a particular version of a native library has been loaded, it can never be unloaded and no other version can ever be used until the JVM is restarted. The impact on Isight and the SIMULIA Execution Engine is that a newly published version of a component may be unusable by a running copy of Isight or by the SIMULIA Execution Engine distributed execution environment. The SIMULIA Execution Engine station requires that all clients be shutdown and restarted to use a newly published version of a component that uses JNI to call native code. As a result, all stations and all Isight clients connected to the SIMULIA Execution Engine have to be shutdown and restarted, which can have a significant impact on large-scale SIMULIA Execution Engine environments.

Isolating the JNI portion of a component can minimize the cases in which a restart is required to deploy an updated version of the component. For more information, see Component Structure.

Classloading

Another restriction imposed by the Java language on JNI code is related to classloaders, which are the means by which Isight and the SIMULIA Execution Engine support the use of multiple versions of the same component and hot-deployment of new versions. Each version of a component is loaded with a unique Java classloader, which allows different versions of the same classes to exist in the JVM at the same time. A full discussion of classloader technology is beyond the scope of this document, but the technology allows the system infrastructure to manage and deploy new versions of components when they are published to the library without the need to stop or restart anything.

JNI code is associated with a single classloader at the time it is first loaded. Java prevents the same native library from being associated with any other classloader, even if it is using the same version of the native library. Thus, a component cannot be updated and redeployed into a running JVM even if the native code has not changed.

Isight provides a means to place part of the component code in a special system wide classloader that is shared for all components. The part of the component placed in the shared loader cannot be versioned (i.e., cannot be updated without a system restart). However, if only part of the component is placed into the shared loader, the remainder of the component can be versioned and hot-deployed as usual. For more information, about how to divide the component into different parts to maximize the code that can be redeployed without restarting, see Component Structure.