<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that there was a relative long discussion about this exact topic in April 2023:<br></blockquote><div><br></div><div>Should multi-module jars be implemented, most issues with problem 2 would be resolved without needing to resort to circular dependencies or requiring the user to remember a bunch of extra service modules. Most apps deploying as a jar would have the optional services work essentially as if they were on the classpath. The one exception to this case I've found is that applications deployed as fully modular jlink runtime images require the optional service modules to be explicitly defined in the module-info or added to the jlink command. (which is a pain for me, as I like using jlink to add my application modules to the runtime)</div><div dir="ltr"><div><br></div><div>This too I've had to deal with by scanning the module info in the processor and giving compiler warnings if a service is detected in the processing environment and not specified in the module-info. It's unfortunate though that this limitation will continue to exist. <input name="virtru-metadata" type="hidden" value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"2","compose-window":{"secure":false}}"></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While I did also run into this issue, I would favor a solution during the build phase. Maybe some project still uses Java 8, where the JDK does not yet know about the module-info. The behavior should not change between different versions of the runtime.</blockquote></div><div><br></div><div>Well, Helidon's baseline is now JDK 21, so Java 8 compatibility shouldn't be a concern. I still think that auto-generating service files with an annotation processor is the way to go if an alternative easier solution cannot be found in this discussion. </div></div></div></div></div></div><br><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Sat, Jan 20, 2024 at 8:19 PM Johannes Spangenberg <<a href="mailto:johannes.spangenberg@hotmail.de" target="_blank">johannes.spangenberg@hotmail.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<blockquote type="cite">
<div><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><b>Ad
2 - Provider module cannot be optional dependency</b></span></div>
<div><span style="letter-spacing:normal;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:16px;color:rgb(0,0,0);background-color:rgb(255,255,255);font-weight:400">-------------------------------------</span></div>
<div><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Problem:
We cannot declare `requires static` on a module that has the
ServiceLoader provider interface (or abstract class)</span></div>
</blockquote>
<p>Note that there was a relative long discussion about this exact
topic in April 2023:</p>
<p><a href="https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/014846.html" target="_blank">https://mail.openjdk.org/pipermail/jigsaw-dev/2023-April/014846.html</a></p>
<p>I personally think that the current implementation is too
restrictive as I see very little gain in this runtime error, but
there was also a noticeable opposition.<br>
</p>
<blockquote type="cite"><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><b>Ad
4 - Duality of definition between classpath and module path</b></span>
<div><span style="letter-spacing:normal;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:16px;color:rgb(0,0,0);background-color:rgb(255,255,255);font-weight:400">-------------------------------------</span></div>
<div><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Problem:
To support services, we MUST declare them twice - once in
`provides` in module-info.java, once through META-INF/services</span></div>
<div><span style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Possible
solution: Java could read module descriptors even when running
in classpath mode to add service implementations and merge it
with META-INF/services information</span></div>
</blockquote>
<p>While I did also run into this issue, I would favor a solution
during the build phase. Maybe some project still uses Java 8,
where the JDK does not yet know about the module-info. The
behavior should not change between different versions of the
runtime.</p>
<p>PS: I am not affiliated with the project, besides being
subscribed to this mailing list.</p>
</div>
</blockquote></div>
</div>