RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK [v3]

[Jiangli Zhou]

On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie <ihse at 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