On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into >> JDK-8355080 >> - Address henryjen@ comment: >> - Remove '#include <jni.h>'. > > This was news to me. I'm thinking about what this means in terms of the > static build, where all native JDK libraries are "loaded" as soon as the > application starts executing. Do we have native libraries in the JDK that are > not loaded by the boot loader? If so, have we introduced some corner case > effects by marking them with the static JNI symbol? 🤔 @magicus For existing JDK JNI native libraries, I think adding `DEF_STATIC_JNI_OnLoad` (if missing) does not affect the classloader usage associated with the library. The static support for built-in JNI native library affects the native "load" operation (e.g. on Linux `dlopen`) only ([Java_jdk_internal_loader_NativeLibraries_load](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L119). Double checking [Java_jdk_internal_loader_NativeLibraries_unload](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L180), the existing code also makes sure `JVM_UnloadLibrary` is not called to "unload" (e.g. on Linux `dlclose`) built-in JNI native library. The reason why boot loader question/consideration brought up in this thread was because `libsyslookup` was not associated with the boot loader but now does with the change in src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2840305879
