<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>