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

[Jaikiran Pai]

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>'.

Hello Jiangli, if I understand this change correctly, then this is forcing a non-JNI library to be a JNI library for it to work on static JDK. Is that a requirement for static JDK builds? Or is it just a convenient way to use existing library loading mechanism in the `jdk.internal.loader.NativeLibraries`?

Are there other similar libraries shipped in JAVA_HOME/lib that would require a similar change/treatment?

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

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