On Wed, 6 Mar 2024 21:22:40 GMT, Jan Lahoda wrote:
>> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line
>> 812:
>>
>>> 810: }
>>> 811:
>>> 812: private static void addEnableNativeAccess(ModuleLayer layer,
>>> Set moduleNames, boolean shouldWarn) {
>>
>> The
On Tue, 5 Mar 2024 18:54:55 GMT, Alan Bateman wrote:
>> 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>
>>
On Wed, 6 Mar 2024 19:00:19 GMT, Alan Bateman wrote:
>> Native access is needed for modules which calls restricted methods [1].
>> AFAICT, java.base, java.desktop and jdk.incubator.vector use
>> java.lang.foreign but I don't know if they call restricted methods or not.
>>
>>
On Wed, 6 Mar 2024 18:00:25 GMT, Mandy Chung wrote:
> Native access is needed for modules which calls restricted methods [1].
In time, we'll need it for modules using JNI too. We can do this trimming in
another PR to avoid Jan getting pulled into deeply.
-
PR Review Comment:
On Wed, 6 Mar 2024 15:02:07 GMT, Jan Lahoda wrote:
>>> Many of these modules do not need native access in the current
>>> implementation.
>>
>> In addition this will eventually need jlink support. I view the change to
>> ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules()
On Wed, 6 Mar 2024 00:56:16 GMT, Jaikiran Pai wrote:
>> I believe we could technically reuse the list for boot/platform modules.
>> But, the intent here is to provide more control over the modules with native
>> access, not only being able to add to the list, but also remove from the
>> list.
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda 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
>>
On Wed, 6 Mar 2024 09:19:44 GMT, Alan Bateman wrote:
>> Many of these modules do not need native access in the current
>> implementation. Should this list be trimmed to list the ones that need
>> native access in the current implementation?
>
>> Many of these modules do not need native
On Tue, 5 Mar 2024 13:58:50 GMT, Jaikiran Pai wrote:
>> 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>
>>
On Tue, 5 Mar 2024 22:44:20 GMT, Mandy Chung wrote:
> Many of these modules do not need native access in the current implementation.
In addition this will eventually need jlink support. I view the change to
ModuleBootstrap initialiser to use ModuleLoaderMap.nativeAccessModules() as
very
On Tue, 5 Mar 2024 16:13:14 GMT, Jan Lahoda wrote:
>> I see. I then misunderstood a part of the PR description.
>
> I believe we could technically reuse the list for boot/platform modules. But,
> the intent here is to provide more control over the modules with native
> access, not only being
On Tue, 5 Mar 2024 18:43:44 GMT, Alan Bateman wrote:
>> 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>
>>
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda 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
>>
On Tue, 5 Mar 2024 14:14:15 GMT, Jaikiran Pai wrote:
>>> to make the intention clear as well as reduce the chances of missing some
>>> boot or platform module in this NATIVE_ACCESS_MODULES?
>>
>> The list to be be granted native access is a subset, it shouldn't be granted
>> all modules
On Tue, 5 Mar 2024 14:01:55 GMT, Alan Bateman wrote:
>> make/conf/module-loader-map.conf line 95:
>>
>>> 93: #
>>> 94:
>>> 95: NATIVE_ACCESS_MODULES= \
>>
>> Hello Jan, does this make configuration allow for something like:
>>
>>
>> NATIVE_ACCESS_MODULES= ${BOOT_MODULES} \
>>
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda 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
>>
On Tue, 5 Mar 2024 13:42:32 GMT, Jaikiran Pai wrote:
> to make the intention clear as well as reduce the chances of missing some
> boot or platform module in this NATIVE_ACCESS_MODULES?
The list to be be granted native access is a subset, it shouldn't be granted
all modules mapped to the boot
On Tue, 5 Mar 2024 12:44:10 GMT, Jan Lahoda 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
>>
> 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
On Tue, 5 Mar 2024 12:41:18 GMT, Jan Lahoda 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
>>
20 matches
Mail list logo
