问题描述

我们使用

加载任何本机库

System.loadLibrary("hello")

现在我知道这个库名是指Windows 的 hello.dll
和 libhello.so for Unix 系统.

那么，这些平台依赖性更改发生在哪里?

JRE在这样做吗?

推荐答案

tl; dr

平台依赖库名称是用Java虚拟机的本机方法构建的.
实际算法只需预处/附加平台特定的前缀/后缀:

• Windows:”hello” – > “hello.dll”
• linux/solaris:”hello” “libhello.so”
• mac:”hello” – > “libhello.dylib”

长版:

有几个JDK Java方法，用于负载库和/或库名称:

java.lang.System.loadLibrary(String name)
java.lang.System.mapLibraryName(String name)
java.lang.Runtime.loadLibrary(String name) 
java.lang.ClassLoader.loadLibrary(String name)

著名的System.loadLibrary实际调用Runtime.loadLibrary Runtime.loadLibrary ClassLoader.loadLibrary.
最后，这些方法的实现调用以下本机方法，该方法翻译给定库名称
进入平台特定名称:

native java.lang.System.mapLibraryName(String name)
native java.lang.ClassLoader$NativeLibrary.findBuiltinLib(String name)

可以在(链接到OpenJDK版本)中找到这些本机方法的实现:

• http://hg.openjdk.java.net/jdk8/jdk8/jdk8/jdk/file/687fd7986d/src/src/share/native/native/java/java/lang/lang/system.c#l466
• http://hg.openjdk.java.net/jdk8/jdk8/jdk8/jdk/jdk/file/687fd7c7986d/src/src/share/native/native/java/java/lang/lang/classloader.cclassloader.c#l495

这两种方法实现了相同的算法来构建实际的库名称，
准备前缀JNI_LIB_PREFIX并附加后缀JNI_LIB_SUFFIX.

最后，宏JNI_LIB_PREFIX和JNI_LIB_SUFFIX在平台依赖性中定义了文件，即

• http://hg.openjdk.java.net/jdk8/jdk8/jdk8/jdk/file/687fd7c7986d/src/src/windows/javavm/javm/export/jvm_md.h#l42
• http://hg.openjdk.java.net/jdk8/jdk8/jdk8/jdk/file/687fd7c7986d/src/src/solaris/javavm/javm/export/jvm_md.h#l43
• http://hg.openjdk.java.net/jdk8/jdk8/jdk8/jdk/jdk/file/687fd7c7986d/src/src/macosx/javavm/javm/export/jvm_md.md.h#l43

其他推荐答案

简短答案:是.

从loadLibrary的javadoc中:”加载由libname参数指定的系统库.将库名称映射到实际系统库的方式依赖于系统.” System.mapLibraryName(libname)将返回映射的库名称.

这反映了库名称的常见约定:lib Linux和Mac OS X中的前缀，Windows中没有前缀，以及平台依赖的文件扩展名.请注意，Mac OS X上JNI库的扩展名是jnilib，而不是dylib，而不是其他库.此外，此映射不是Java运行时唯一的，gcc … -lhello也将寻找libhello.so(或Mac OS X上的libhello.dylib).

如果您不希望运行时间进行此映射，则必须确定正确的文件名，包括扩展名，并将其传递给loadLibrary

以上所述是小编给大家介绍的在加载JNI库时，如何与实际的库名进行映射？,希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对77isp云服务器技术网的支持！