<div dir="auto"><div dir="auto">We also raised the same issue a while back.</div><div dir="auto"><br></div><div dir="auto"> <a href="https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/date.html#14853">https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/date.html#14853</a></div><div dir="auto"><br></div><div dir="auto">A possible solution that was discussed was to have a mechanism to have multiple modules in a single jar. (But obviously that hasn't been implemented yet) </div><div dir="auto"><br></div><div dir="auto">We managed to solve it in our library via a circular plugin dependency. (Library A has a dependency on Plugin B which depends on an older version of library A to provide A's functionality to Library C) </div><div dir="auto"><br></div><div dir="auto">It's pretty painful to setup/modify, but if you don't expect the spi implementation to change that much it works I guess.</div><div dir="auto"><br></div><div dir="auto">Even so I also wish there was an easier way to provide optional services so we don't have to go through that whole circular song and dance.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2025, 12:58 PM David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank" rel="noreferrer">david.lloyd@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It is not uncommon for a library to contain a provider for a service where the service resides in an optional dependency. It is also sometimes desirable to use a service from an optional dependency.</div><br clear="all"></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In JPMS, we can use `requires static` to indicate that the library will function without the dependency being present. We can declare that we use or provide a service from the optional dependency. Compilation will complete successfully in this case, because the descriptor is valid.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">However, at run time, the module will fail to resolve if any provider or uses comes from a module that is not present when the layer is resolved. This is not desired behavior, because the user has already opted in to and indicated that the dependency in question is optional, and should not cause a run time problem if not present.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The current behavior is inconsistent between compile and run time, and should be revisited.</div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>
</blockquote></div></div>