Enable native access for modules not in the boot layer

[Johannes Kuhn]

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