<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="">
<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 18 Apr 2023, at 16:01, 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="ltr" class="">
<div dir="ltr" class="gmail_attr">On Tue, Apr 18, 2023 at 8:46 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank" class="">ron.pressler@oracle.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><br class="">
</div>
<div class="">Which makes me wonder, what is the root of the optionality in your code? I.e. how does io.avaje.inject come to be resolved?<br class="">
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">So avaje jsonb/config/http implements SPI interfaces exported by avaje inject(which is added as a maven optional dependency). The idea here is that the plugin implementation would be loaded by avaje-inject to add to the DI scope.</div>
<div class=""><br class="">
</div>
<div class="">Outside of avaje inject, these service implementation classes have no meaning and are not meant to be instantiated. In some cases, the service implementation package may not even be exported by the module, so even if you tried you couldn't instantiate
outside of a service loader.</div>
<div class=""><br class="">
</div>
<div class="">Does this help answer your question? Or did I misread it?</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}}" class=""></div>
</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
I think so, thank you. But when the application runs in a particular configuration, the application deployer knows whether or not that configuration uses the avaje inject module. If it does not, why is the configuration including the service module?
<div class=""><br class="">
</div>
<div class="">The class path has a loosy-goosey attitude, but modules are all about creating a proper configuration. Ideally, there shouldn’t be any modules that could not possibly be used.</div>
<div class=""><br class="">
</div>
<div class="">We could discuss making modules more laid back in some specific situations, but generally, they exist so that we could have a strict configuration. So I guess my question now is, why would you want to allow a particular application configuration
to include a module that could not possibly be used in that configuration?</div>
<div class=""><br class="">
</div>
<div class="">I assume the answer is to avoid the need to document to the user that if they choose to use some capability offered by module X (avaje inject) they should also add module Y (the service provider). If we were more lenient, you could just give them
module Y, and then all would work whether or not they choose to use X. But the flip side of that is that if they choose not to use X, Y would just sit there, unused. Best case scenario, it would just increase their image size; worst-case scenario is that it
could preclude some future optimisations that may require a full program analysis. </div>
<div class=""><br class="">
</div>
<div class="">To do this properly, as Alan alluded, `requires static` is insufficient because the module doesn’t know where the service interface is supposed to come from. Rather, we would need a new specific mechanism that says “if module X is readable, then
provide this service”. To know how important such a feature is we need to understand the source of the problem: why is it hard to exclude unused modules? </div>
<div class=""><br class="">
</div>
<div class="">— Ron</div>
</body>
</html>