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

[Magnus Ihse Bursie]

On Wed, 23 Apr 2025 00:56:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this PR that changes to use `NativeLibraries.loadLibrary()` for loading the `libsyslookup` in `jdk.internal.foreign.SystemLookup` class.
>> 
>> `NativeLibraries.loadLibrary()` handles both the shared library and (static) built-in library loading properly. On `static-jdk`, calling `NativeLibraries.loadLibrary()` for `systlookup` library can find the built-in library by looking up using `JNI_OnLoad_syslookup`. The current change adds `DEF_STATIC_JNI_OnLoad` in syslookup.c (in shared, windows and aix versions) for that purpose.
>> 
>> In addition to GHA testing, I tested the change on static-jdk with jdk tier1 tests on linux-x64 locally. All java/foreign/* jdk tier1 tests pass with the change. Without the change, there are about 60 java/foreign/* jdk tier1 tests fail on static-jdk.
>
> 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? 🤔

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2837654312