RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37]

[Maurizio Cimadamore]

On Thu, 5 May 2022 16:39:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `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

Thanks for the comments. I've pushed a new change which fixes a couple of thing:

* first, for `SymbolLookup.loaderLookup`, the system class loader is used when no caller class exists (e.g. when method is called from JNI). If caller class exist but its loader is null (boot loader), we just call ClassLoader::findNative with a `null` loader which will do the right thing (thanks @mlchung for the tips!)

* second, the restricted method check in `Reflection::ensureNativeAccess` has been improved to also work in case where caller class is `null`. In such cases, a dummy unnamed module module is used for the check.

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

PR: https://git.openjdk.java.net/jdk/pull/7888