To dynamically load the user’s native methods, it is necessary in Java to call, for example, the method System.loadLibrary().
A new name is formed from the name specified in loadLibrary(), under which the library is then searched for. This name is lib<name>.so
The library is searched for using the environment variable LD_LIBRARY_PATH. The first description file found using this method is then used to dynamically load the appropriate module or modules.
The JVM and the native methods of Java are held in separate shared libraries and loaded into separate contexts in each case. Thus, if JVM interfaces which extend beyond the JNI interface are used (which they should not be), the corresponding dependencies to the shared Libraries should be entered in the user libraries.
When the first C++ method is started a C++ runtime system is loaded dynamically (including the tools and standard library) and C++ is initialized, if this has not already been done.
During dynamic loading of shared libraries (BIND macro), at present the system does not search through the “share scope” to resolve any open external references as this would mean it could no longer be guaranteed that the Java private CRTE or sockets will be used.
This must likewise be done if the user himself dynamically loads via BIND code, at least when references to the C runtime system and the sockets exist.
Java native methods and main modules containing them cannot be pre-loaded with the current linking loader.