BackEnd Service Provider.

[Gary Frost]

Thanks for both looking  into this

I have an IntelliJ workaround that sort of works (I will pass on to John
Rose, because he reported the same issue to IntelliJ), which is obvious in
hindsight.  I launch outside of IDE using --patch-module and get the
process to wait, then attach from IDE. This gets around issue of IDE not
honouring --patch-module.  So I can at least debug in IDE.

Just some more feedback on misspent hours ;)

I actually modified JDK13 to allow me to pass in a property (name of
factory implementing org.graalvm.compiler.hotspot.HotSpotBackendFactory)
and built. Then of course the issues was that my factory was not in the
classpath ;)  I tried creating a classloader seeded via  a jar name (via
another property) but it all went downhill fairly fast...  after that...
curses were shouted... dogs were kicked and beer was consumed.

So clearly --patch-module not only allows replacing 'system' classes, it
allows all the other classes in the patched path, to be treated as if they
were on system classpath, ala ye olde -Xbootclasspath.

Anyway again, thanks for having a look, and possibly keeping this type of
usecase in mind was we try to allow access to graal.  It would be nice to
make this easy for folk.

PS. No dogs were really harmed, during the classloading hacking.

Gary

On Wed, Apr 22, 2020 at 8:31 AM Doug Simon <doug.simon at oracle.com> wrote:

> 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 <Alan.Bateman at oracle.com> 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
>
>