<div dir="auto"><div>Thanks for the explanation, it clears up why things are the way they are. </div><div dir="auto"><br></div><div dir="auto">Even so, I'm not necessarily interested in only the modules I'd get in a single "round." I'd like to add extra modules for the service classes I specify via an arg, even across multiple rounds.<br><br>That is, my application module info doesn't have any `uses` statement, but some of the required dependencies have multiple uses statements. I'd like a way to resolve only the modules for specific spi classes, not all that the dependency uses.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023, 4:56 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/06/2023 05:31, Josiah Noel wrote:<br>
> I know how to use --suggest-providers as well, my issue is that it's <br>
> tedious to have to parse the output and manually add each module.<br>
><br>
><br>
> It'd make my workflow a lot simpler if I could just name the service <br>
> class and have jlink resolve all the modules that provide it.<br>
><br>
<br>
As you've found, jlink doesn't do service binding by default. The <br>
assumption is that most jlink users wants fine control over the modules <br>
that go into the run-time image. The --suggest-providers option was to <br>
help fine tune of service providers to specify to jlink to include.<br>
<br>
As has been mentioned, there is --bind-services option if needed. <br>
Service binding is iterative to allow service provider modules <br>
themselves make use of services. Usages of --bind-services can therefore <br>
lead to run-time images include modules that is hard to explain, or <br>
developers fighting the option with --limit-modules.<br>
<br>
I think what you are asking for is a way to do one round of service <br>
binding. On the surface this may be okay but it might have the same <br>
issues as --bind-services in that some developer will want all services <br>
that provide an implementation of S except they want to exclude want P8 <br>
and P37. P8 may be required by some other module so it can't be <br>
excluded. It gets hard to explain.<br>
<br>
We went explored this area a bit in JDK 9 and converged on keeping it <br>
simple: let someone configuring the jlink command decide which service <br>
provide module to include. I'm not saying this shouldn't be re-visited, <br>
just trying to summarize why it is the case.<br>
<br>
-Alan<br>
</blockquote></div></div></div>