<div dir="ltr"><i>> Yes > <span style="color:rgb(80,0,80)">Does this work without<span class="gmail-Apple-converted-space"> </span></span><span style="color:rgb(80,0,80)">any</span><span style="color:rgb(80,0,80)"><span class="gmail-Apple-converted-space"> </span>module having a `requires y.inject`? </span></i><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">Awesome.</span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"><br></span></div><div><i><span style="color:rgb(80,0,80)">> </span>If there is no module on the module path that uses the x.spi.Plugin, the y.inject module will not resolve, and no exception will be thrown.</i></div><div><br></div><div>Awesome.</div><div><br></div><div><br></div><div><br></div><div><b>Summary: (as this thread has got massive)</b></div><div><br></div><div>The suggested future Java that supports multiple modules in a single jar would indeed solve this issue and "just works". To me at least, it looks like it solves it <i>perfectly</i> without any negative side effects or downsides.</div><div><br></div><div>The only followup questions I can see regarding multiple modules in a single jar are:</div><div>- Would this solution be intended to work for older versions of Java at runtime like Java 11? We probably can't answer this yet but open source libs tend towards supporting a minimum version based on LTS for better or worse (and will be keen to know if they can adopt this by using the latest build tooling but still support older/existing java runtimes. If so, I would think that would greatly help the adoption of the 2 modules in 1 jar solution).</div><div>- For my own personal interest, what are the other motivations for supporting multiple modules in a single jar? (If these other motivations are high that improves our chances of seeing this solution happen)</div><div><br></div><div><br></div><div><br></div><div><b>Workarounds today</b></div><div><br></div><div>For myself as I see it the workarounds that are available today are:</div><div><br></div><div>- *[1] Not using ServiceLoader. This is relatively simple and has only 1 downside which is that the implementation must be in an exported package. As such, this is still my preferred workaround (but it's certainly not the ideal longer term solution). </div><div>- [2] Changing the design by "reversing the relationship" e.g x at runtime detects y. This will work in some cases but isn't going to work generally or at scale. </div><div>- [3] Splitting the artifact / Have a separate jar for the optional service implementation</div><div> - [3a] Make users aware of this and require the plugin dependency to be explicitly included in the path. This is not ideal for the case where there are 000s of users and now has "stuff it up" by default behaviour (people forget to include the dependency).</div><div> - [3b] Use a maven composite dependency and document/promote that as the dependency to use (So 3 artifacts now, ok'ish).</div><div> - **[3c] Use maven transitive dependency to by default transparently include the plugin dependency (most closely matches the 2 modules in 1 jar approach)</div><div><br></div><div>For people interested I have put a skeleton of this at: <a href="https://github.com/rbygrave/skeleton-optional-service">https://github.com/rbygrave/skeleton-optional-service</a></div><div><br></div><div>For people interested, the top 2 workarounds today as I see them are:</div><div>*[1] Not using ServiceLoader. </div><div>**[3c] Use maven transitive dependency ... which I have as a PR at: <a href="https://github.com/rbygrave/skeleton-optional-service/pull/1">https://github.com/rbygrave/skeleton-optional-service/pull/1</a> This uses a slightly dirty build trick to workaround the maven cyclical dependency. This can be considered ok if the plugin implementation is very stable (which I expect to hold true).<br></div><div><br></div><div><br></div><div>**[3c] To me this is the closest thing to the "2 modules in 1 jar" solution<br></div><div><br></div><div><br></div><div>Cheers, Rob.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 25 Apr 2023 at 16:33, Josiah Noel <<a href="mailto:josiahnoel@gmail.com">josiahnoel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Does this work without <i>any</i> module having a `requires y.inject`? </div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> If so, how is the y.inject module get included without a<span> </span>`requires y.inject` being specified? </div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It will resolve when a module uses the x.spi.Plugin it provides. (x in this case) Hence, there is no need for any module to require y.inject. (as it doesn't export anything).</div><div dir="auto"><br></div><div dir="auto">If there is no module on the module path that uses the x.spi.Plugin, the y.inject module will not resolve, and no exception will be thrown.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="line-break:after-white-space">
</div>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div>