On Mon, 28 Apr 2025 13:04:57 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
> > 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. > > I remember this wasn't quite as elegant on Windows, but I suppose there is > already some solution in place to look up symbols that are statically linked > into the same executable? With the current effort for enhancing/completing static JDK support, the system is able to detect if it's running on static using checks like `is_vm_statically_linked/JVM_IsStaticallyLinked/JLI_IsStaticallyLinked`. For example, `os::native_java_library` (https://github.com/openjdk/jdk/blob/2f8448034f28276ad5ac1edfa0fb8650e47d4ffa/src/hotspot/share/runtime/os.cpp#L516) and `load_zip_library` retrieve the `os::get_default_process_handle` without doing `dlopen` (e.g. on Linux) to load the native libraries. For longer term, we can make the solution more coherent/general for handling the various cases in the system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836196239
