<div dir="auto"><div dir="auto"><br></div><div dir="auto">> Ron: I’m guessing that what’s bothering you isn’t so much the number of *modules* but the number of JARs. So I think a more general solution than adding a way to describe “this service is conditional on the presence of X” would be to allow multiple modules in a single JAR that would contain both Y and the X-Y-plugin. </div><div dir="auto"><br></div><div dir="auto">How would this solve the issue? I can't see how having a second module on the same jar/artifact would work for this case. </div><div dir="auto"><br></div><div dir="auto">Bearing in mind this library needs to support both classpath and module-path. </div><div dir="auto"><br></div><div dir="auto">If a y.jar could include 2 module definitions say y and y.x what would be defined in y.x that solve this issue? Can you be more explicit Ron? (I can't see this working tbh) </div><div dir="auto"><br></div><div dir="auto">Instead of a second module my gut says that what would solve this is a: </div><div dir="auto"><br></div><div dir="auto"> 'provides static'</div><div dir="auto"><br></div><div dir="auto">... where that explicitly means that runtime module resolution should allow the service interface to not exist. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Cheers, Rob.</div><div dir="auto"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Apr 2023, 1:56 am Josiah Noel, <<a href="mailto:josiahnoel@gmail.com" target="_blank" rel="noreferrer">josiahnoel@gmail.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="auto"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The reason why this could be considered acceptable is because the implementation of x.spi.Plugin that would exist in Y can be hidden / not exported and not open to abuse / accidental use.<br></div></blockquote><div><br></div>This also helps resolve that concern on the bug report.</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><span style="color:rgb(23,43,77);font-family:"DejaVu Sans",sans-serif;font-size:14px">All of this boils down to: if the implementation module says `provides`, then is it reasonable to consider that ServiceLoader is the *only* vector by which the implementation class will be instantiated? If yes, then module resolution should perhaps be tolerant of a `provides` that specifies a missing service interface. If no -- that is, we think arbitrary code might instantiate (hence load) the implementation class -- then module resolution is correct as-is.</span></blockquote><div> </div><div>if we don't export the implementation class, then the ServiceLoader becomes the only mechanism by which it can be instantiated. In this case, if the user doesn't add the optional interface dependency, it becomes impossible to accidentally load the interface and get a ClassNotFoundException when using module Y's non-SPI packages.</div><div><br></div></div><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":"8","compose-window":{"secure":false}}"></div></div>
</blockquote></div></div>