> 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.
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. Bearing in mind this library needs to support both classpath and module-path. 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) Instead of a second module my gut says that what would solve this is a: 'provides static' ... where that explicitly means that runtime module resolution should allow the service interface to not exist. Cheers, Rob. On Fri, 21 Apr 2023, 1:56 am Josiah Noel, <josiahn...@gmail.com> wrote: > 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. >> > > This also helps resolve that concern on the bug report. > > 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. > > > 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. > >
