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