I see, thanks for the clarification. It's a pity, though, I hoped to employ that approach for providing a custom jlink plug-in (implementation of jdk.tools.jlink.plugin.Plugin). So it seems that's not possible until jdk.jlink exports j.t.j.plugin? Are there any plans to do so some time soon?
Even if it was marked as experimental/incubating, being able to provide custom jlink plug-ins would enable interesting use cases. 2017-11-20 22:24 GMT+01:00 Alan Bateman <alan.bate...@oracle.com>: > On 20/11/2017 21:04, Gunnar Morling wrote: > >> Hi, >> >> I'm having one module which defines a service interface but does not >> export >> that interface's package. In another module I wish to create an >> implementation of that service, which should be possible via >> --add-exports. >> >> I can successfully compile that second module, but running it fails: >> >> Error occurred during initialization of boot layer >> j.l.m.ResolutionException: Module com.example.b does not read a >> module >> that exports com.example.a >> >> It seems as if the service binding happens before the --add-exports of the >> java invocation is processed. Please see below for the steps to reproduce. >> >> Is it a bug or am I trying to do something unsupported here? >> >> At run-time, the --add-reads/--add-exports options are the equivalent of > the module invoking addReads or addExports. So yes, they come into effect > after resolution and service binding (and so after the resolution > consistency check that detects that a module uses a service type in a > package that isn't exported by anyone to the module). > > -Alan >
