RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37]
Mandy Chung
mchung at openjdk.java.net
Thu May 5 16:42:25 UTC 2022
On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.
>
> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).
>
> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.
When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame.
It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk.
[1] https://bugs.openjdk.java.net/browse/JDK-8281001
-------------
PR: https://git.openjdk.java.net/jdk/pull/7888
More information about the shenandoah-dev
mailing list