Hello Gary. Here is a pull request that turns the project structure into a set of three Maven modules:
https://github.com/grfrost/graal_service_issue/pull/1 As Maven is more approachable to common Java IDEs, one can use for example GraalVM's Ideal Graph Visualizer to edit, compile, run & debug the project. See the pull request for detailed instructions. Best regards. Jaroslav Tulach NetBeans Platform Architect OracleLabs Dne středa 22. dubna 2020 11:16:22 CEST, Gary Frost napsal(a): > 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.si...@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.bate...@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.compile > > r` 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
