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.
That feature is something we could very much consider (subject to prioritisation, of course). Would you consider that a satisfactory solution? — Ron P.S. In the meantime, here’s what you could do, and that — in my opinion — *is* an acceptable use for `requires static X`: In module Y (which doesn’t include the plugin) rely on `requires static X` to test, at runtime (say in a static initialiser of a class that’s part of Y’s main functionality), whether or not X is available, also whether the plugin is available. If X is available and the plugin isn’t, you could issue a message telling your users: please add the plugin module. On 21 Apr 2023, at 16:02, Josiah Noel <josiahn...@gmail.com<mailto:josiahn...@gmail.com>> wrote: I see, I believe I fully understand your concerns. It makes the module version of ServiceLoader a lot less useful to me, but I see your main hesitation. In your scenario, Y is pulling double duty, which makes it harder to understand overall, and you'll benefit a lot more from breaking it up than from a more relaxed module system. Perhaps I'm looking at it from the wrong angle, but from a maintenance perspective, I'm not really seeing the benefits. Say you have 5 artifacts that provide an optional service for X, to support the module-path we now need to maintain 10. It also makes it somewhat cumbersome to add the extra dependencies to use them all with X.
