On 21/04/2020 14:01, Doug Simon wrote:
Hi Gary,

I cannot understand why --add-reads does not work and have reached out to Alan Bateman for more insight.

I read through the thread [1] and I don't see an obvious solution to this.

The main issue here is that org.grfstuff.compiler wants to provide an implementation of org.graalvm.compiler.hotspot.HotSpotBackendFactory but that service type is not in org.grfstuff.compiler and org.graalvm.compiler.hotspot is not exported to org.grfstuff.compiler by any of the modules that it reads. The post resolution consistency check that it trips up on is specified in the Configuration API docs if you are interested.

I assume `--add-exports jdk.internal.vm.compiler/org.graalvm.compiler.hotspot=org.grfstuff.compiler` was added in an attempt to workaround this but that CLI option is the equivalent of jdk.internal.vm.compiler invoking Module::addExports after the module graph has been reified. It doesn't impact resolution or any of the post resolution consistency checks at run-time. Yes, there is an unfortunate difference between between compile-time and run-time in this regard but that is something for another discussion.

I don't think there are any obvious workarounds. The Module API defines addXXX methods to export or open packages at run-time, extend readability or add a service dependences but it doesn't define addProvides. I think it came up once during JDK 9 but more in the context of symmetry rather than a compelling use-case. It's not clear that the issue under discussion here is compelling enough, needs more thought as the scenario is a bit weird. If org.grfstuff.compiler was co developed with jdk.internal.vm.compiler then it could use a qualified export of course.

Initially I thought you could workaround this by moving org.grfstuff.compiler  to the class path but this it's not going to work as ServiceLodaer usage in Graal seems to use module layers as congtext, so it will not find implementations on the class path.

-Alan

[1] https://mail.openjdk.java.net/pipermail/graal-dev/2020-April/005949.html

Reply via email to