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

[Jorn Vernee]

On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore <mcimadamore 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>'.
>
> The changes here look good. Essentially, if `syslookup` is statically linked, trying to do a `dlopen` on it will fail, as the shared library for it doesn't exist. For this reason, this PR seems to "upgrade" syslookup to a JNI library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a "builtin" library -- that is, a library for which no dynamic linking should occur.
> 
> The loaded library is associated with the boot classloader. This could be problematic, in principle. However, since the requests to `loadLibrary` also come from the boot loader (they are from the `SystemLookup` class) it all works out ok.
> 
> Having to upgrade to JNI is a bit sad -- although I get that it is required as a workaround for now. For the longer term I'd prefer a better way to integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` does when it comes to static libraries is to return the so called "process handle" -- e.g. a handle to the running process (the JVM). If there was a way to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it would be possible to avoid the JNI dance: just get the process symbol lookup, and look for statically linked symbols in there.

> @mcimadamore
> 
> > Having to upgrade to JNI is a bit sad
> 
> I'm not quite sure what you mean that "upgrades" the library to a "JNI library"? Nor why this is sad?

JNI libraries are more restrictive than non-JNI libraries, as JNI libraries can only be loaded by a single class loader. The lifetime of the class loader is re-used as the lifetime of the library, and tells us when OnLoad and OnUnload should be called. This is in particular not needed in this case, and gets us away from the loaded-by-single-class-loader restricted, but as Maurizio says, making this library a JNI library is probably okay, since this class should always be loaded by the boot loader.

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

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