On 18 Apr 2023, at 16:01, Josiah Noel <josiahn...@gmail.com<mailto:josiahn...@gmail.com>> wrote:
On Tue, Apr 18, 2023 at 8:46 AM Ron Pressler <ron.press...@oracle.com<mailto:ron.press...@oracle.com>> wrote: 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? 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. 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. Does this help answer your question? Or did I misread it? 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? 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. 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? 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. 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? — Ron
