On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda <jlah...@openjdk.org> wrote:
>> Currently, JDK modules load by the bootstrap and platform ClassLoaders are >> automatically granted the native access. I am working on an upgrade of JLine >> inside the `jdk.internal.le` module, and I would like to replace the current >> native bindings with FFM-based bindings (which are now somewhat provided by >> JLine). But, for that, native access is needed for the `jdk.internal.le` >> module. We could possibly move the module to the platform ClassLoader, but >> it seems it might be better to have more control over which modules have the >> native access. >> >> This patch introduces an explicit list of modules that will automatically be >> granted the native access. Note this patch is not yet intended to change the >> end behavior - the list of modules granted native access is supposed to be >> the same as modules in the boot and platform ClassLoaders. > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> > Co-authored-by: Maurizio Cimadamore > <54672762+mcimadam...@users.noreply.github.com> Some of the files updated in this PR need a copyright year update. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 817: > 815: JLA.addEnableNativeAccessToAllUnnamed(); > 816: } else if (!JLA.addEnableNativeAccess(layer, name) && > shouldWarn) { > 817: warnUnknownModule(ENABLE_NATIVE_ACCESS, name); Should we instead warn irrespective of whether or not it's user configured native access module name or a module name configured in JDK's build configuration? Or are the build misconfiguration in the `NATIVE_ACCESS_MODULES` expected to be caught much earlier in some other place? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18106#issuecomment-1978836356 PR Review Comment: https://git.openjdk.org/jdk/pull/18106#discussion_r1512869279