<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>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><br class="">
</div>
<div>That feature is something we could very much consider (subject to prioritisation, of course). Would you consider that a satisfactory solution?</div>
<div><br class="">
</div>
<div>— Ron</div>
<div><br class="">
</div>
<div>P.S.</div>
<div>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.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 21 Apr 2023, at 16:02, Josiah Noel <<a href="mailto:josiahnoel@gmail.com" class="">josiahnoel@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="auto" class="">
<div class="">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. </div>
<div class=""><br class="">
</div>
<div dir="auto" class="">
<div class="gmail_quote" dir="auto" style="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In your scenario, Y is <br class="">
pulling double duty, which makes it harder to understand overall, and <br class="">
you'll benefit a lot more from breaking it up than from a more relaxed <br class="">
module system.<br class="">
</blockquote>
<div class=""> </div>
<div class="">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.<br class="">
</div>
<div class=""></div>
</div>
</div>
<div dir="auto" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
</div>
</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":"1","compose-window":{"secure":false}}" class=""></div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>