Enable native access for modules not in the boot layer
Johannes Kuhn
info at j-kuhn.de
Mon Jun 6 21:24:01 UTC 2022
On 06-Jun-22 23:03, Maurizio Cimadamore wrote:
> Hi Johannes,
> I think this is a direction we wanted to explore, but we didn't have
> time to (but it's something we will have to look into before the API is
> finalized). >
> The approach you propose is similar to some ideas I've exchanged with
> Chris and others few months ago, and I agree that it would be useful to
> support something like that, for dynamic loading of modules.
The same applies to delegating opens/exports. (exports can not be
delegated - bad if you want to split a module that relies on consumer
modules exporting packages to your module...)
I am happy to hear that this problem is known and therefore will be solved.
My prototype is just meant as a suggestion - and make my point
(hopefully) more clear.
>
> One note: I believe your code will have better chances in 19, since now
> lack of --enable-native-access will only result in a warning, not an
> error. That should give some of the currently unsupported use cases some
> way to get up and running, while we add support for
> --enable-native-access to all the corresponding areas.
I already have a reproducer for 19 (same repo, different branch):
https://github.com/DasBrain/PanamaRuntimeModule/tree/jdk-19
run.bat/run.sh has still the --enable-native-access - but if that is
removed, I get the following warning:
WARNING: A restricted method in java.lang.foreign.Linker has been called
WARNING: java.lang.foreign.Linker::nativeLinker has been called by
module plugin
WARNING: Use --enable-native-access=plugin to avoid a warning for this
module
Ironically, if I add that command line parameter (back), I get an other
warning and an exception:
WARNING: Unknown module: plugin specified to --enable-native-access
Exception in thread "main" java.lang.IllegalCallerException: Illegal
native access from: module plugin
at
java.base/jdk.internal.reflect.Reflection.ensureNativeAccess(Reflection.java:125)
at java.base/java.lang.foreign.Linker.nativeLinker(Linker.java:197)
at plugin/plugin.PanamaTest.main(PanamaTest.java:8)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at launcher/launcher.Launcher.main(Launcher.java:24)
If you want to improve the warning, check if the caller module is in the
boot layer and omit the last line :).
- Johannes
>
> Thanks
> Maurizio
>
> On 06/06/2022 12:53, Johannes Kuhn wrote:
>> In a short discussion with Jorn Vernee I asked how to enable native
>> access for modules not present in the boot layer, and got this answer:
>>
>> > I don't think we have an API for doing that at the moment. But, I
>> didn't really work on this part. If you have a small reproducer,
>> please send it into panama-dev at openjdk.java.net
>>
>> Reproducer: https://github.com/DasBrain/PanamaRuntimeModule
>>
>> I sincerely believe that this is not an unreasonable requirement.
>> But we can argue over that :)
>>
>> ----
>>
>> After looking a bit deeper into how native access is implemented, I
>> also came up with a prototype:
>>
>> https://github.com/openjdk/jdk/pull/9040/files
>>
>> It adds a `Module.enableNativeAccess()` method. That method is itself
>> restricted - and can be used to "delegate" a module's own native
>> access to an other module, similar to how `Module.addOpens` works.
>>
>> I also added `boolean Module.isNativeAccessEnabled()` - which was
>> previously only visible through the shared secrets - but when exposing
>> the enable part, then exposing the check part also makes sense IMHO.
>>
>> ----
>>
>> I would be happy to hear your opinions and suggestions on that topic.
>> Things doesn't have to be implemented that way. It's just a suggestion
>> (where I am sure that it does at least work _technically_).
>>
>> - Johannes
More information about the panama-dev
mailing list