Thanks for your valuable input Alan.
So until the VM provides an --add-provides option (which is not currently
planned), --patch-module is the only mechanism for dynamically adding providers
of otherwise “sealed” Graal services. We could indeed make Graal service
loading look for providers on the class path but that would have to be off by
default and thus require a command line option (e.g.
-Dgraal.AllowServicesOnClassPath=true). However, that doesn’t seem like any
less effort than having to use --patch-module.
-Doug
> On 22 Apr 2020, at 09:12, Alan Bateman wrote:
>
> 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
